WO2015003364A1

WO2015003364A1 - Apparatus and method for two-way timestamp exchange

Info

Publication number: WO2015003364A1
Application number: PCT/CN2013/079217
Authority: WO
Inventors: Qingfeng Yang; Guoliang GAO; Jun Wang
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2013-07-11
Filing date: 2013-07-11
Publication date: 2015-01-15

Abstract

A first network entity is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol. The first network entity comprises one or more line card modules for interfacing with the plurality of communication links. A controller module comprising a two-way timestamp exchange protocol port is mapped with a shadow port on a said line card module, such that the first network entity is configured for a two-way timestamp exchange with the second network entity via a said shadow port.

Description

APPARATUS AND METHOD FOR TWO-WAY TIMESTAMP EXCHANGE

Technical Field

The present invention relates to an apparatus and method for two-way timestamp exchange, for example a two-way timestamp exchange relating to a precision time protocol, PTP.

Background

Mobile backhaul (MBH) is a transport network that provides connectivity from radio access base stations (or cell sites) to their corresponding control and switching elements located deeper in the core of a telecommunications network, i.e. the network that connects to the backbone of the telecommunications network. Mobile backhaul is currently an important area of technological advance, since the mobile backhaul will play an important part in ensuring that future networks are able to cope with the demands being imposed by

applications such as wireless broadband, and the ever increasing traffic requirements being placed on telecommunication networks.

In mobile backhaul, distribution of synchronization information is a vital feature. Without proper synchronization information mobile networks are unable to function correctly. For example, in terms of Wideband Code Division Multiple Access (WCDMA), or Long Term Evolution Frequency Division Duplexing (LTE FDD), frequency synchronization is very important. The general requirement on an air interface is a frequency accuracy of 50 ppb between two base stations, as specified by the Third Generation Partnership Project (3GPP) specifications. One of the purposes is to minimize disturbance on the air interface to secure handover between radio base stations.

Newer mobile communication technologies require synchronized phase and precise Time of Day (ToD) in addition to synchronized frequency. Among these technologies are LTE Time Division Duplexing (LTE-TDD), Mobile WiMAX/TDD, Time Division Synchronous Code Division Multiple Access (TD-SCDMA), and Femtocell technology. The general requirement on the air interface is a frequency accuracy of 50 ppb and a phase/ time accuracy of the order of 1 sec (e.g. CDMA200 > ±3 psec, LTE-TDD large cell > ±5 psec, LTE-TDD small cell > ±1 .5 sec).

As mentioned above, accompanying the development of mobile backhaul is the dramatic increase in data traffic and transmission. Mobile backhaul over

Ethernet is becoming a more popular technology. Introducing time and

frequency synchronization for Ethernet is therefore becoming more critical.

Distributing phase and time information using a Precision Time Protocol (PTP), as defined in IEEE technical specification 1588-2008, is an emerging packet based technology that is popular with most telecommunication service providers, accompanying the boom in PTP telecommunication profiles. PTP is a protocol used to synchronize clocks throughout a network.

However, even though PTP is currently one of the areas of significant interest in the telecommunications industry, it is comparatively new, since the usable standard was only finalized in 2008. As a result, many mechanisms which are applied in a traffic network, to make the traffic network more efficient, do not consider this specific packet based time distribution technology and its special requirements (which tend to be very hardware dependent). In addition, some popular mechanisms being used in traffic networks may even affect the PTP function.

One such mechanism that can affect the functionality of a PTP function is a path diversity resiliency mechanism, which can cause path availability issues in a PTP function, as explained below.

In a modular system, certain mechanisms can cause a PTP function to become unavailable. For example, in a typical traffic network protection mechanism, such as a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) protection switch, a PTP path can suddenly become unavailable when the protection switching mechanism switches to another path. Likewise, an Internet Protocol interface (IP-if) or a Virtual Local Area Network interface (VLAN-if ) that employs link aggregation groups, LAG, can result in a PTP path becoming unavailable, for example when a link member of a LAG fails, or when link members are added to, or deleted from a LAG. Figure 1 a shows a typical network entity 101 in a MPLS-LSP link protection application. MPLS-LSP link protection switching and node-link protection are facility-based methods used to reduce the amount of time needed to reroute LSP traffic. Link protection and node-link protection can protect multiple LSPs by using only a single, logical bypass LSP, for example whereby a label-switched path 109 via line card 103i may be protected using a backup label-switched path 1 10 via a line card 103₂. It is noted that the line cards 103i and 103₂ are also referred to as service module (SM) cards. An active controller 105 and standby controller 107 are known as shelf controller cards, also referred to as main controller cards.

Link protection can provide robust backup support for a link, node-link protection can bypass a node or a link, and both types of protection are designed to interoperate with other vendor equipment. Such functionality makes link protection and node-link protection excellent choices for scalability, redundancy, and performance in MPLS-enabled networks.

Protection switching is a method of ensuring recovery from link or node failure with minimal disruption to the data traffic. In protection switching, data is switched from a failed active LSP (such as LSP 109) to a backup LSP (such as LSP 1 10) at the repair point. The backup LSP 1 10 is usually pre-provisioned, with data typically being switched back to the active LSP 109 after it is restored.

In multi-chassis modular systems, to provide LSP protection the active LSP link 109 and its backup LSP link 1 10 are always connected to different service modules (SMs) or line cards (LCs) 103i and 103₂.

A disadvantage of a protection mechanism such as that described above is that, for certain functions that are highly hardware connection dependent, such as PTP timestamp exchange, this LSP protection switch/restore will affect their performance and availability. For example, a hardware dependent function such as PTP that is running on a processing unit of the first line card 103i may no longer be available when the LSP 109 is rerouted to the backup LSP 1 10 associated with a different line card 1032.

Referring to Figure 1 b, similar problems can arise when providing time messages over an Internet Protocol interface (IP-if) or a Virtual Local Area Network interface (VLAN-if ). Figure 1 b shows a network entity 101 connected with a first link 109 provided via a first line card or service module 103i and a backup link 1 10 provided via a second line card or service module 103₂, with an active controller 105 and standby controller 107 being provided for controlling the first and second line cards 103i and 1032. IP-if and VLAN-if are Layer 3 logical interfaces. For protection purposes, IP-if and VLAN-if map to a VLAN, which is in turn mapped over a plurality of physical ports. A IP-if or VLAN-if is operational (or "Up") only when at least one physical port added to the corresponding VLAN is Up. The data transported though this Layer 3 interface is finally over a specific physical port, and when this physical port or the physical link connected to it is down, data will be re-routed to another available physical port and link. For example, when the link 109 or the port which interfaces with the first line card 103i is down, the IP-if or VLAN-if will be switched to a backup link 1 10 associated with the second line card 103₂.

As a result, in a similar manner to the problems discussed for the LSP protection mechanism of Figure 1 a, IP-if and VLAN-if can also induce

availability problems to certain functions that are highly hardware connection dependent, such as PTP. For example, a hardware dependent function such as PTP that is running on a processing unit of the first line card 103i will no longer be available when the IP-if or VLAN-if via link 109 is switched to the backup link 1 10 associated with a different line card 103₂.

Figure 2 shows an example of a PTP architecture in a chassis or modular system. Two typical PTP architectures are popularly applied in a modular system, these being known as a distributed architecture and a centralized architecture. Figure 2 shows a typical centralized architecture having a plurality of line cards (also known as service modules, SMs) 2011 to 201 _N and a plurality of controller cards (also known as service cards, SCs) 204i to 204_M. A distributed architecture is similar, but whereby functional units 1588 server selection 213, time synchronization algorithm 215 and digitally controlled oscillators/phase-locked loop 207 are moved from the controller card 204 to the line card 201 .

In a centralized architecture a user can create only one PTP instance, which resides on both a line card 201 and a controller card 204. For the benefit of cost reduction, from a hardware perspective, the main component of PTP clock recovery (a high precision crystal oscillator 21 1 , such as a temperature- controlled crystal oscillator TCXO or an oven-controlled crystal oscillators OCXO) resides on the controller card 204. For the benefit of scalability, and from a software perspective, the PTP application together with a best-master- clock-algorithm (BMCA) and a configuration recovery adaptor (CRA) reside on a CPU, e.g. a processing unit 205, of the controller card 204. A PTP protocol engine and PTP packet transporting and processing functions reside on a CPU, e.g. a processing unit 203, of the line card 201 .

In a distributed architecture a user can create a number of 1588 instances in the same node, with each 1588 instance residing on one line card 201 . For the benefit of redundancy, each different 1588 instance is independent, and includes full 1588 functionality (such as PTP clock recovery, digitally controlled oscillators (DCO) 207 and CRA, PTP protocol stack, PTP packet transporting & processing). From a system perspective, there are redundant PTP clients that can be used.

In a centralised architecture or a distributed architecture, the line cards comprise a physical layer (PHY)/switch with timestamp support 202, Regardless of whether a centralised architecture or a distributed architecture is used, the widely-deployed packet network protection mechanisms (such as LSP protection and IP-ifA/LAN-if) will induce PTP path unavailability in the chassis or modular system, which will result in the unavailability of the PTP function. Figure 3 shows a basic diagram of a line card module 103 that is configured to handle a precision time protocol, PTP. The line card module comprises a plurality of ports 321 1 , 321₂, to 321 _n which can communicate with other network entities via a plurality of communication links (not shown). A processing unit 301 comprises a PTP protocol stack 306 and a data transport module 305. A data transport module 305 is configured to support packet based time distribution via the plurality of ports. The processing unit 301 further comprises a number of functional units for handling other functions performed by the line card module, for example a link aggregation group (LAG) functional unit 302 for handling the aggregation of two or more communication links for increased bandwidth and/or resiliency, a MPLS functional unit 303 for handling Multi Protocol Label Switching communication, and a IP functional unit 304 for handling Internet Protocol communication.

If any of the ports 3211 to 321 _n become unavailable for any reason, for example through a protection mechanism that causes communication to be moved to another link and hence another port, then a PTP function being performed by the processing unit 301 may no longer be available.

Summary

According to a first aspect of the present invention there is provided a first network entity is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol. The first network entity comprises one or more line card modules for interfacing with the plurality of communication links. A controller module comprising a two-way timestamp exchange protocol port is mapped with a shadow port on a said line card module, such that the first network entity is configured for a two-way timestamp exchange with the second network entity via a said shadow port.

Optionally, the first network entity comprises a plurality of shadow ports representing a two-way timestamp exchange protocol port. The network entity is configured to select one of said plurality of shadow ports to transmit/receive timestamp messages for the two-way timestamp exchange protocol port.

Optionally, the first network entity further comprises: a monitoring unit configured to detect a change in the status of at least one of the plurality of communication links between the first network entity and the second network entity, resulting in one or more of the shadow ports becoming unavailable. The first network entity further comprises a coordinating unit configured, in response to the monitoring unit detecting a change in status, to coordinate with other line card modules to determine which shadow port should be used to replace a shadow port that has become unavailable, such that the determined shadow port is used for communicating subsequent timestamp messages of the two- way timestamp exchange with the second network entity.

Aspects of the invention allow a two-way timestamp exchange protocol (e.g. PTP) port to remain available by using representative shadow ports configured for the timestamp protocol. For example, communication with a shadow port can be switched if necessary to another shadow port which is also connected to the same two-way timestamp exchange protocol (e.g. PTP) port. According to another aspect of the present invention there is provided a line card module for use in a network which is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol. The line card module is configured to be controllable by a controller module, wherein the line card module comprises a shadow port for a two-way timestamp exchange protocol port on the controller module, such that a two-way timestamp exchange with the second network entity can take place via a said shadow port.

According to another aspect of the present invention, there is provided a method in a first network entity which is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol. The method comprising the step of

providing one or more line card modules for interfacing with the plurality of communication links. The method further comprising the step of mapping a two- way timestamp exchange protocol port on a controller module with a shadow port on the line card module, such that a two-way timestamp exchange with the second network entity is via a said shadow port.

According to another aspect of the present invention, there is provided a computer program product, configured when run on a computer to conduct a method according to any one of methods defined in the appended claims. Brief description of the drawings

For a better understanding of examples of the present invention, and to show more clearly how the examples may be carried into effect, reference will now be made, by way of example only, to the following drawings in which:

Figure 1 a shows an example of a communication network for communicating precision time protocol, PTP, messages over a multi-protocol label switching, MPLS, system;

Figure 1 b shows an example of a communication network for communicating precision time protocol, PTP, messages over a IP/VLAN interface, IP-ifA/LAN-if;

Figure 2 shows an example of a PTP architecture in a chassis/modular system;

Figure 3 shows an example of a known line card module for use with a precision time protocol;

Figure 4a shows a network entity according to an embodiment of the present invention;

Figure 4b shows a method in a network entity according to an embodiment of the present invention; Figure 5 shows a line card module according to an embodiment of the present invention;

Figure 6 shows a schematic diagram illustrating the operation of a shadow port according to an embodiment of the present invention; Figure 7 shows an example of how embodiments of the present invention may be used in an example application; and

Figure 8 shows a method according to another embodiment of the present invention.

Detailed description

The embodiments of the invention will be described below with reference to a two-way exchange of timestamp messages in a precision time protocol (PTP) application. It is noted, however, that the embodiments of the invention can be used with any form of two-way timestamp exchange protocol, as defined in the appended claims. As such, references to a PTP in the embodiments below are intended to include any two-way timestamp exchange protocol. Similarly, references to a PTP port in the embodiments below are intended to include any two-way timestamp exchange protocol port.

The embodiments of the invention provide an apparatus and method for reducing or eliminating performance degradation in a two-way timestamp exchange protocol such as PTP, due to the unavailability of the timestamp message path.

Figure 4a shows a network entity 500 according to an embodiment of the present invention, which is capable of communicating over a plurality of communication links with a second network entity (not shown) using a two-way timestamp exchange protocol. The network entity is a modular network entity. The network entity comprises one or more line card modules 401 1 to 401 N for interfacing with the plurality of communication links. The network entity comprises a module 410 that is configured to map a two-way timestamp exchange protocol port with a shadow port on a said line card module 4011 to 401 N, such that a two-way timestamp exchange with the second network entity can take place via a said shadow port. A two-way timestamp exchange protocol port may comprise, for example, a PTP port that is configured by a controller card or controller module of a network entity, wherein a PTP port maps to a physical port, such as LAN ports 421 of a network entity (shown in dotted lines in Figure 4a for clarity). In some aspects, a plurality of the ports 421 communicate with a plurality of

communication links forming a resiliency diversity mechanism, and optionally, a link aggregation group (e.g. LAG or Multi-Chassis link aggregation group (MC- LAG)). The network entity is configured to use a different one of a plurality of shadow ports if required by the diversity protection mechanism.

The mapping of a two-way timestamp exchange protocol port with a shadow port has the benefit of enabling two-way timestamp exchange messages, such as PTP messages, to continue being sent between the network entity and another network entity, even when a particular link has failed, or been changed due to a reconfiguration (for example link members of a link aggregation group being changed, or failing).

In a distributed architecture the module 410 can reside on each line card modules 401 to 401 _N, as shown by the modules 41 d to 410_N in Figure 4a. It is noted, however, that in a centralised architecture one or more modules 410 may be located centrally, for example on a centralised controller card, and

configured to communicate with a plurality of line card modules. Figure 4b shows a method in a first network entity according to an embodiment of the present invention, whereby the first network entity is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol. The method comprises the step of providing one or more line card modules for interfacing with the plurality of communication links, step 501 . The method further comprises the step of mapping a two-way timestamp exchange protocol port on a controller module (e.g. on a controller card) with a shadow port on the line card module, such that a two-way timestamp exchange with the second network entity can take place via a said shadow port, step 509. The two-way timestamp exchange in the embodiments of Figures 4a and 4b may constitute part of a precision time protocol, PTP, although as mentioned above other forms of two-way timestamp exchange are also intended to be covered by embodiments of the invention. Figure 5 shows further details of a line card module of Figure 4a, according to an embodiment of the present invention. The line card module 401 comprises one or more physical ports, for example Ethernet local area network (LAN) ports 421 1 to 421 n, which can communicate with a second network entity via a plurality of communication links (not shown). A processing unit 301 comprises a PTP protocol stack 306 and a data transport module 305. The data transport module 305 is configured to support packet based time distribution via the plurality of physical ports. The processing unit 301 further comprises a number of functional units for handling other functions performed by the line card module, for example a link aggregation group (LAG) functional unit 302 for handling the aggregation of two or more communication links for increased bandwidth and/or resiliency, a MPLS functional unit 303 for handling Multi Protocol Label Switching communication, and a IP functional unit 304 for handling Internet Protocol communication. It is noted that other functional units may also be provided within the processing unit 301 .

According to this embodiment of the invention, the line card module is configured to be controllable by a module 410, wherein the line card module 410 comprises a shadow port for a two-way timestamp exchange protocol port on the module 410, such that a two-way timestamp exchange with the second network entity can take place via a said shadow port. The module 410 comprises a functional unit referred to hereinafter as a "Unified PTP Transport Adaptor" 308. The Unified PTP Transport Adaptor 308 interfaces with the PTP protocol stack 306, a PTP port Mapping Table 309, an active path supervision module 31 1 , a shadow PTP port coordinator 310, and the data transport module 305 .

The Unified PTP Transport Adaptor 308 triggers these other modules to work, and obtains each user configured PTP port (i.e. two-way timestamp exchange protocol port) and provides port mapping information, the PTP port mapping information being stored in the PTP port Mapping Table 309.

The Unified PTP Transport Adaptor 308 is configured to check with the Data transport module 305 (for example a datacom subsystem) to determine whether a PTP port mapping is based on a link aggregation group, LAG, VLAN-if, IP-if, or Label Switched Path, LSP, with protection. As such, the Unified PTP

Transport Adaptor 308 checks whether the PTP port mapping is of the type that can affect the performance of the PTP function.

In the event that any of these PTP port mapping cases exist, and the line card is involved with these, then the Unified PTP Transport Adaptor 308 can trigger the local PTP protocol stack 306 to create a shadow port (for example a shadow PTP port) for each PTP port. The shadow port is a part of the PTP protocol stack. In particular, the shadow port is stored in the local PTP port Mapping Table 309. A single shadow port may be created for each PTP port, or alternatively a plurality of shadow ports for each PTP port.

It is noted that a PTP port may be created by a central controller card, while shadow ports are created by line card modules. A PTP port is part of the PTP stack, the PTP stack being the main entity which processes PTP messages and runs a state machine. In some aspects, the PTP stack is the protocol engine configured to process any PTP packet belonging to its PTP port. The PTP port Mapping Table 309 can therefore be configured to maintain: a list of shadow ports available on its respective line card module; and a list of shadow ports available on any peer line card modules of the network entity. The Unified PTP Transport Adaptor 308 is also configured to trigger the

Shadow PTP port Coordination module 310 to coordinate with its peer modules on other line cards to determine the active shadow port which is to be used to transmit/receive PTP messages. The Shadow PTP port Coordination module 310 may be triggered in this way in response to the module 410 determining that a particular PTP port has failed, as described later in the application.

Therefore, the Shadow PTP port Coordinator 310 is configured to handle the availability issues in a modular system for the highly hardware connection dependent functions of PTP. The PTP port mapping table 309 stores mapping information for PTP ports and associated shadow ports. It contains all the PTP ports and relevant mapping information, and also contains the shadow ports which reside on this line card module 401 . The Active Path Supervision module 31 1 , also referred to herein as a monitoring unit 31 1 , is configured to detect a change in the status of at least one of the plurality of communication links between the first network entity and the second network entity, resulting in one or more of the shadow ports becoming unavailable. The module 410 is configured to use a shadow port in response to the Active Path Supervision module 31 1 (monitoring unit) detecting that a corresponding PTP port has become unavailable.

The Active Path Supervision module 31 1 is configured to supervise the active PTP message path, via which the PTP port / Active PTP shadow port is transmitting/receiving PTP messages. Once this path becomes faulty, or switchover takes place due to the impact of the transportation technologies mentioned earlier, such as protection mechanism, the Active Path Supervision module 31 1 triggers the Shadow PTP port Coordination module 310 to negotiate which shadow port is to be used to replace an unavailable shadow port.

From the above it can be seen that there is provided a line card module that comprises a mapping table configured to maintain a list of: shadow ports available on the line card module; and shadow ports available on any peer line card modules of the network entity. The line card module comprises a

monitoring unit configured to detect a change in the status of at least one of the plurality of communication links between the line card module and a second network entity, resulting in one or more of the shadow ports of the line card becoming unavailable, and a coordinating unit configured, in response to the monitoring unit detecting a change in status, to coordinate with other peer line card modules to determine which shadow port should be used to replace a shadow port that has become unavailable, such that the shadow port is used for communicating subsequent two-way timestamp messages with the other network entity. Figure 6 provides a further explanation of how a shadow port is used with a PTP function, and the operation of the various functional elements of a controller module. In Figure 6 the controller card 404 is shown as being configured in a centralized architecture, although it is noted that the controller 404 may also be configured in a distributed architecture, distributed to reside across line cards within a network entity, as shown in Figures 4a and 5. In this example, one shadow port 41 1 is shown on each of a plurality of line cards 401 , the plurality of shadow ports representing (and connected to) the same PTP port 412. The PTP port 412 can be considered on a controller module on the controller card 404. The controller card 404 is connected to a plurality of line cards 401 in a modular system. A plurality of the line cards 401 comprise the shadow ports connected and representing the PTP port 412. The PTP port 412 can be considered as the entity with which a further (second) network entity communicates.

In some examples, a Shadow PTP port 41 1 on a line card 401 is the

representative or agent of a specific PTP port 412 on a controller card 404. In some aspects, the Shadow port 41 1 is a part of the PTP protocol stack 306. The shadow ports are connected to a physical port 421 .

The shadow port 41 1 is the entity that sends and receives PTP messages. The fields in a PTP message are taken from a PTP port dataset, for example a port identifier (port ID). As such, peer PTP network entities are only aware that they are talking to a PTP port, rather than a shadow port associated with that PTP port. The shadow port has all the attributes of the connected two-way timestamp exchange protocol (e.g. PTP) port. The shadow ports 41 1 are not configured by the operator. Instead, the shadow ports are configured by the PTP port 412, e.g. located on the controller card 404. In some aspects, the shadow ports are triggered to be created as a function of the controller card 404. A shadow port 41 1 (for example a shadow PTP port) or a plurality of shadow PTP ports may be created for each PTP port. The shadow PTP ports reside on the line cards where the members of the PTP port mapping technology are located, for example LAG members, VLAN members, LSP protection link members. The PTP port mapping technology is used to encapsulate and carry PTP messages to be transported between a master network entity and a slave network entity. The PTP shadow ports 41 1 take over all the processing functions of the PTP port. However, the shadow port is configured such that the separate network entity communicating with the shadow port considers that the communication is with the PTP port, not the shadow PTP port.

When a user creates a PTP port 412 in a controller card or module 404 (either centralized or distributed), whereby the PTP port is related to a communication such as VLAN or LAG in which path availability might be a issue, then the controller module 404 will trigger a PTP stack 306 to generate one or more, or a plurality of, shadow PTP ports 41 1 corresponding to each PTP port. For example, the shadow PTP ports 41 1 are on a bench of line cards where the VLAN/LAG members are located.

A shadow port, for example a shadow PTP port, is the representative or agent of a specific PTP port on a controller module. The attributes of a shadow PTP port are cloned from the specific PTP port. A plurality of shadow PTP ports may be created for the specific PTP port, one per each line card. The shadow ports have the same attributes as the port represented.

The controller module comprises a two-way timestamp exchange protocol instance arranged to provide a configuration interface to an operator. The line cards or shadow ports do not provide a further instance in a centralized architecture. Thus, the only instance of a PTP port and representative shadow ports is on the controller module (controller card). In a distributed architecture, each line card comprises a protocol instance. In an example of the invention, the shadow ports are configured through the PTP port. The shadow ports are not configured directly on each line card. This contrasts to the prior art, where configuration of a PTP port on each line card is needed, for both centralized and distributed architecture.

In some aspects, the line cards provide the timestamping function of the two- way timestamp protocol. In particular, the line cards provide timestamp abstracting from a PTP message, and timestamp generating on a local physical port. Thus, although the plain timestamp packet could be sent through to the controller card, the PTP packet must have a timestamp on this local line card. In the prior art, the PTP path/link is no longer available. However, the use of shadow ports of a PTP port enables the PTP port to remain available, even when a protection mechanism uses a different line card.

The line cards also co-ordinate PTP shadow ports on different line cards to determine and re-select/set-up PTP message path in the network entity. The line card also comprises the PTP protocol stack and shadow port created according to triggering by the controller module, and PTP message

sending/receiving.

In some aspects, the controller card (or controller module) provides the only PTP instance. The controller card creates/maps the PTP port on the controller card and triggers the line cards to create shadow ports. The controller card also carries out BMCA, CRA and local clock adjusting according to the timestamps from the line card. During runtime, the Shadow PTP port Coordination module 310 of the module 410 will coordinate shadow PTP ports 41 1 on a line card to react on the bottom layer of a transport technology change, for example a diversity protection mechanism, a LSP protection switch, a packet network protection mechanism, e.g. IP-if/VLAN-if path protection group change, or a LAG link change.

Examples of the invention are applicable to any diversity protection mechanism. In some aspects, the diversity protection mechanism is any diversity protection mechanism except for LAG or MC-LAG. Examples of the invention provide a selection between connections according to availability. Aspects of the invention are configured such that a link remains available via a further shadow port 41 1 , even when an original shadow port becomes unavailable. Since the timestamp communication is considered by an external network entity to be with the PTP port (and not a shadow port), an unavailable shadow port does not render the PTP port unavailable. In particular, the PTP port maintains availability by a switch to a different active shadow port. This contrasts with the prior art, in which a link between a PTP port and an external network entity can be broken, even if the link has a backup as part of a diversity protection mechanism.

Tables 1 and 2 of Figure 6 are examples of some of the information that may be contained in a PTP port Mapping Table 309. In particular, referring to Table 1 of Figure 6, the first line card 4011 (i.e. in line card (LC) slot 1 ) is shown as having shadow port 1 active, which corresponds to the third LAN port 421₃ (i.e. third physical port) of the first line card 401 1. The second line card 401₂ is shown as having shadow port 2 passive, which corresponds to the first LAN port 421 1 (i.e. first physical port) of the second line card 4012. The passive shadow port 2 is not currently active. Referring to Table 2, each item represents a PTP shadow port, and contains information relating to the PTP port that the shadow PTP port belongs to (i.e. "PTP Port ID"), the physical ports on the local line card that this PTP port is mapping to (i.e. "LANx port"), the status of this PTP shadow port ("Status"). In this example an optional feature "SVID-opt" relates to a feature whereby there is a Service Vlan bond to the physical ports, and whereby '"LSP-opt" relates to a feature in which there is a MPLS LSP label bond to the physical ports, both of which are extension of "LANX port" which is the physical port of the relevant PTP shadow port.

The information in these tables will change when communication moves from one shadow port to another shadow port, whereby the status is changed such that a current shadow port is changed to "Passive" and the other shadow port changed to "Active".

In some examples, the line cards 401 are connected to another network entity by a resiliency or diversity protection mechanism. A change in the resiliency or diversity protection mechanism can result in the change of the active shadow port.

Figure 7 shows a typical application of an embodiment of the invention, and in particular relating to an application in which PTP messages are communicated over a LAG, and whereby a link failure occurs.

Figure 7 shows a first network entity 500 operating as a slave node and a second network entity 700 operating as a master node. The master node 700 (second network entity) is shown as comprising a single line card 4013, although it is noted that the master node 700 may comprise multiple line cards and/or one or more controller card. The line card 401₃ comprises a processing unit 3013, and a plurality of physical ports, in this example a first physical port 42131 and a second physical port 42132- The processing unit 3013 comprises a PTP protocol stack 3Ο63. The processing unit 3013 comprises a module 4103 according to an example of the invention. The module 410₃ comprises a Unified PTP transport Adaptor 308₃, a PTP port Mapping Table 309₃, a Shadow PTP port Coordination module 3103, and an Active Path Supervision module 31 13, the functions of which are as described above in Figures 5 and 6, and below in Figure 8.

The slave node 500 (first network entity) is shown as comprising a modular architecture having first and second line cards 401 1 and 4012, each controlled by a respective processing unit 3011 and 301₂, with each line card 401 1 and 4012 configured to communicate via respective physical ports (LAN ports 421 1 and 4212 in this example). The plurality of line cards are connected to a controller card 404. In this example, the line cards are connected to a plurality of controller cards 404, an active and standby controller card. The controller cards 404 comprise a PTP port 412.

Each processing unit 301 1 , 3012 comprises a PTP protocol stack 306 and a respective module 410i and 410₂ according to an example of the invention. Each module 410 comprises a Unified PTP transport Adaptor 308, a PTP port Mapping Table 309, a Shadow PTP port Coordination module 310, and an Active Path Supervision module 31 1 . It is noted that a slave node 500 or a master node 700 may comprise a different number of lines cards than that shown in Figure 7, and/or a different number of physical ports per network entity and/or line card.

In the example of Figure 7 the line cards are assumed to be communicating via MPLS (although it is noted that similar procedures would be applied when using PTP over IP-if/VLAN-if). An active LSP link is shown between LAN port 421₂ of the second line card 4012 of the slave node 500 and the LAN port 42131 of the master node 700, with a backup LSP link provided between LAN port 421 1 of the first line card 401 1 of the slave node 500 and LAN port 421₃₂ of the master node 700.

It is assumed that there is a failure of the active LSP link, and that a new link needs to be selected for a PTP time message. As a result, the active LSP link between LAN ports 421₂ and 421₃ goes into fault, resulting in the active link plus the physical ports 421₂ and 421₃ being unavailable, such that all traffic will be re-located to the backup LSP link. On the second network entity 700, as a first step the Active Path Supervision module 31 13, which as mentioned above monitors the current status of the active link, will detect this failure and acquire the link member change in LSP, and will direct the PTP message to the backup LSP link. Then, according to the selected link in the backup LSP, the Shadow PTP port Coordination module 3103 will trigger the information in the PTP port Mapping Table 3093 to be updated accordingly. The port 42132 is then used instead of 421 31. On the first network entity 500, as a first step the Active Path Supervision module 31 1 2 on the second line card 401₂ will also detect the link member change in the LSP, i.e. because the Active Path Supervision module 31 12 is monitoring the active LSP link, and will immediately ask all other shadow PTP ports belonging to the same PTP port to check on the backup LSP links. This means that all other PTP shadow ports belonging to the same PTP port will check on the backup LSP link.

As a second step on the first network entity 500, the Shadow PTP port

Coordination module 31 1₂ asks shadow PTP ports to capture the next PTP message from the second network entity 700 (master).

As a consequence, the first line card 401 1 will capture that a PTP shadow port 41 1 on Line card 1 401 1 , which maps to the physical LAN port 421 ^ also on the first line card 401 1 can receive the PTP message from the second network entity 700 (master), via the backup LSP which has been set up. This results in the new representative shadow PTP port 41 1 , for example PTP shadow port 1 (mapping to physical LAN port 421 ^ being elected.

In this way the module 410 is configured to request shadow ports 41 1 to capture a next timestamp message transmitted from the second network entity, identify which shadow port has captured the next timestamp message, and select the identified shadow port as the port to be used for communicating subsequent timestamp messages with the second network entity.

Meanwhile, the Active Path Supervision module 31 1 1 on the first line card module 401 1 also captures that the egress PTP message from the master to PTP shadow port 1 is via LAN port 1 (421 1 ).

As a third step on the first network entity 500, on the second line card 401₂ the Unified PTP Transport Adaptor module 3Ο82 sets the PTP shadow port 2 to be "inactive/passive" in the local PTP port Mapping Table 3092, and also notifies the local PTP stack 306₂ to change the PTP shadow port 2 to be "DISABLED". Furthermore, on the first line card 401 1 , the Unified PTP Transport Adaptor module 308i sets PTP shadow port 1 to be "active" in the PTP port Mapping Table 309i, and notifies the local PTP stack 306i to set the PTP shadow port 1 in the state as PTP port. The Unified PTP Transport Adaptor module 3811 records that the new designated interface for PTP shadow port 1 is the LAN port 1 (4211 ) into its PTP port Mapping Table 309i . All the PTP messages transmitted/received by the PTP shadow port 1 to the master node 700 will use this physical LAN port 1 (LAN port 421 1 ).

In this way the line card module 401 1 local to the selected shadow port is configured to determine which physical port of that line card module is associated with the selected shadow port, and designate that physical port as being the selected shadow port for communicating with the second network entity.

The PTP shadow port is still a logical port and cloned from PTP port. Below the PTP shadow port resides the physical ports, the LAN ports 421 , which are responsible for sending/receiving packets. All the physical ports, which are beneath all the PTP shadow ports, belonging to a group such as LAG/ IP interface/ VLAN interface/ MPLS LSP group. The group is mapped to the PTP shadow port, as described in the context of Figure 6.

As a result, a new PTP message path between the first network entity 500 and second network entity 700 (acting as Slave/Master PTP ports) is re-built.

If a change occurs such that another physical LAN port which belongs to another PTP shadow port takes over the communication responsibility, then the status of the currently active PTP shadow port will be changed to "Passive".

It can be seen from the above that a new PTP LSP message path between the slave node 500 (the first network entity) and the master node 700 (the second network entity) is re-built, and that a path is always made available for communicating messages, thereby avoiding synchronization issues caused by timestamp messages being failed to be delivered because of path unavailability issues. The PTP function is able to determine that the path for communicating PTP messages has changed, and continue to exchange PTP messages over the backup path without affecting PTP performance due to unavailability.

In some examples, the PTP port continues to receive results from the PTP shadow port, e.g. notification of the other network entity communicating with the PTP port and/or timestamps of a packet from the other network entity. In particular, the identification of the PTP port 412 visible to the second network entity is not changed. The active shadow port 41 1 continues to carry out the primary functions of a PTP port, e.g. on the line card.

Figure 8 shows the steps performed by another embodiment of the present invention.

In step 801 an Active Path Supervision module (or monitoring unit) 31 1 x of a specific line card module 401 x of a network entity 500 detects that a status of a link connecting the network entity with another network entity has changed. For example, the change in status may be due to a link fault, a link switchover because of a fault, or a link change for some other reason, such as a change in a diversity protection mechanism (e.g. LSP) protection, IP-if/VLAN-if) or the addition/deletion of a link member to/from a link aggregation group, LAG.

In step 803 it is determined whether the system is a modular system. If not, then processing ends. This is because in a non-modular system the availability issue is not so critical, since a central PTP port will receive a packet and relevant timestamps as long as there is a path from the master to the slave, no matter via which physical port. However, in a modular system, if the alternative path is changed to another line card (i.e. a different line card), then the PTP port cannot receive all the information it needs, i.e. cannot receive the timestamps locally, even though the packet may still be received. If it is determined in step 803 that the system is a modular system, a Shadow PTP port Coordination Module 310 on the specific line card module 401 (the Shadow PTP port Coordination Module 310 of the local line card module 401 that is affected by the link change, as detected by the Active Path Supervision module 31 1 ) detects this status change.

In step 809, this specific Shadow PTP port Coordination Module 310 informs peer line card modules 401 of the status change.

Each peer line card module 401 triggers their respective Active Path

Supervision modules 31 1 to check the DATA Transport format, step 813. This step is performed to determine whether a peer line card module 401 has a DATA Transport format that might adversely affect PTP functionality, for example LSP or IP-if or VLAN-if. In step 813, it is determined whether the link member (such as LSP/IP-if/VLAN- if link member) on each line card is currently active. In this way, each of the peer line card modules 401 will check to determine which backup link (LSP/IP- if/VLAN-if backup link) is being used. The backup link being used will have been established by another network entity, for example a master network node that has itself determined the change is status of a link, and arranged for the backup link to be established. If no other link is active, this means that a backup link has not been established on the network entity, and processing therefore ends since a shadow port cannot be established. This is the case since there is no "NO" flow from decision box 813. It is noted that step 813 performed on each peer line card module. If it is determined in step 813 that a LSP/IP-if/VLAN-if link on a line card is currently active, a local Shadow PTP port of that line card module is set as "Active", and the local PTP stack notified to set the local shadow PTP port in the state as PTP port, step 815.

In parallel with steps 807 to 815, the Shadow PTP port Coordination Module 31 Ox informs the local Unified PTP Transport Adaptor module 308x to take action, step 817. This involves setting the local shadow PTP port "inactive", step 819. This reflects the fact that the local shadow PTP port is no longer available. Furthermore, The Unified PTP Transport Adaptor module 308x triggers the local PTP stack 306x to set the local shadow PTP port to a "Disabled" state, and periodically synchronize the port datasets from PTP port. Since a shadow PTP port is coned from a PTP port, some attributes of a PTP port are dynamic, which therefore need to be synchronized at runtime. In this way the line card module local to an unavailable port is configured to update the mapping table of that line card module to record the identified shadow port as being disabled from communicating PTP messages for another communication link.

The embodiments of the invention provide a method and apparatus to help resolve or eliminate the influence on PTP performance cause by PTP

timestamp message path unavailability, due to diversity protection mechanism, e.g. MPLS LSP, IP-lf/Vlan-lf. In particular, shadow PTP ports are provided to facilitate the communication of PTP port messages in modular system. The functional entity referred to above as a Shadow PTP port Coordination module can handle the availability issues in a modular system for highly hardware dependent functions, such as PTP.

It is noted that even with changes to the bottom layer of a transport technology, for example, in a diversity protection mechanism, or in in some aspects, e.g. LSP protection switching, LAG link faults, IP-if/VLAN-if path changes, a PTP port according to an example of the invention can still keep working normally to send/receive timestamp (e.g. PTP) messages without interruption. The

embodiments of the invention described above therefore provide an improved PTP performance in a modular system, by handling PTP path availability issues. Examples of the invention still use the existing connections that I P- if/VI a n -if/LS P protection group already set up, examples of the invention provide a selection between the connections according to availability.

The described functions and modules may be embodied in a processor, for example, a processor running a computer program.

It should be noted that the above-mentioned embodiments illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word "comprising" does not exclude the presence of elements or steps other than those listed in a claim, "a" or "an" does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1 . A first network entity which is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol, the first network entity comprising:

one or more line card modules for interfacing with the plurality of communication links; and

a controller module comprising a two-way timestamp exchange protocol port mapped with a shadow port on a said line card module, such that the first network entity is configured for a two-way timestamp exchange with the second network entity via a said shadow port.

2. A first network entity as claimed in claim 1 comprises a plurality of shadow ports representing a two-way timestamp exchange protocol port, wherein the network entity is configured to select one of said plurality of shadow ports to transmit/receive timestamp messages for the two-way timestamp exchange protocol port.

3. A first network entity as claimed in claim 1 or 2, further comprising:

a monitoring unit configured to detect a change in the status of at least one of the plurality of communication links between the first network entity and the second network entity, resulting in one or more of the shadow ports becoming unavailable; and

a coordinating unit configured, in response to the monitoring unit detecting a change in status, to coordinate with other line card modules to determine which shadow port should be used to replace a shadow port that has become unavailable, such that the determined shadow port is used for communicating subsequent timestamp messages of the two-way timestamp exchange with the second network entity.

4. A first network entity as claimed in any one of the preceding claims, wherein the shadow ports are arranged on a plurality of line card modules connected to different links or paths of a diversity protection mechanism or packet network protection mechanism.

5. A first network entity as claimed in any one of the preceding claims, wherein each of the one or more line card modules comprises a mapping table, each mapping table being configured to maintain:

a list of shadow ports available on its respective line card module; and a list of shadow ports available on any further line card modules of the network entity.

6. A first network entity as claimed in claim 5, wherein the network entity is configured to determine which shadow port should be used to replace a shadow port that has become unavailable, using the information contained in a said mapping table.

7. A first network entity as claimed in any one of the preceding claims, wherein the controller module is further configured to:

request a plurality of shadow ports to capture a next timestamp message transmitted from the second network entity;

identify which shadow port of the plurality of shadow ports has captured the next timestamp message; and

select the identified shadow port as the shadow port to be used for communicating subsequent timestamp messages with the second network entity.

8. A first network entity as claimed in claim 3, wherein a change in status comprises one or more of:

a failure of one or more link members of the plurality of communication links between the first network entity and the second network entity; or

a failure of a link member of the plurality of communication links between the first network entity and the second network entity carrying timestamp messages of the two-way timestamp exchange; or

an addition of a link member to the plurality of communication links between the first network entity and the second network entity; or

a deletion of a link member from the plurality of communication links between the first network entity and the second network entity; or

a change to a communication link caused by a resiliency diversity mechanism; or

a change to a link member in a label switched path protection mechanism; or

a link change to an internet protocol interface, IP-if; or

a link change to a virtual local area network interface, VLAN-if.

9. A first network entity as claimed in any one of the preceding claims, wherein the line card modules comprise a two-way timestamp exchange protocol stack, wherein the shadow port is a part of the stack.

10. A first network entity as claimed in any one of the preceding claims, wherein the controller module comprises a two-way timestamp exchange protocol instance arranged to provide a configuration interface to an operator.

1 1 . A first network entity as claimed in any one of the preceding claims, wherein the one or more shadow ports are clones of the two-way timestamp exchange protocol port.

12. A first network entity as claimed in any one of the preceding claims, wherein the first network entity is configured such that, on a failure or change of a link of the plurality of communication links using a first shadow port which is active in two-way timestamp exchange with the second network entity, the two- way timestamp exchange is switched from the first shadow port to a second shadow port, wherein the two-way timestamp exchange protocol port is the same for the first and second shadow ports.

13. A first network entity as claimed in any one of the preceding claims, wherein the plurality of communication links comprise a protection group for one or more of: a link aggregation group, LAG, or a multi-chassis link aggregation group MC-LAG, or include protection group for a multi-protocol label switching label switched path, MPLS-LSP, or include a protection group for an Internet Protocol interface, IP-if, or include a protection group for a virtual local area network interface, VLAN-if.

14. A first network entity as claimed in any one of the preceding claims, wherein the two-way timestamp exchange protocol comprises a precision time protocol, PTP.

15. A line card module for use in a first network entity which is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol, the line card module configured to be controllable by a controller module,

wherein the line card module comprises a shadow port for a two-way timestamp exchange protocol port on the controller module, such that the first network entity is configured for a two-way timestannp exchange with the second network entity via a said shadow port.

16. A line card module as claimed in claim 15, further comprising:

a monitoring unit configured to detect a change in the status of at least one of the plurality of communication links between the line card module and the second network entity, resulting in one or more of the shadow ports of the line card becoming unavailable; and

a coordinating unit configured, in response to the monitoring unit detecting a change in status, to coordinate with other peer line card modules to determine which shadow port should be used to replace a shadow port that has become unavailable, such that the shadow port is used for communicating subsequent two-way timestamp messages with the other network entity.

17. A method in a first network entity which is capable of communicating over a plurality of communication links with a second network entity using a two-way timestamp exchange protocol, the method comprising the steps of:

providing one or more line card modules for interfacing with the plurality of communication links; and

mapping a two-way timestamp exchange protocol port on a controller module with a shadow port on the line card module, such that a two-way timestamp exchange with the second network entity is via a said shadow port.

18. A method as claimed in claim 17, further comprising the steps of:

detecting a change in the status of at least one of the plurality of communication links between the first network entity and the second network entity, resulting in one or more of the shadow ports becoming unavailable;

and coordinating with other peer line card modules to determine which shadow port should be used to replace a shadow port that has become unavailable, such that the shadow port is used for communicating subsequent two-way timestamp messages with the other network entity.

19. A computer program product, configured when run on a computer to conduct a method according to claim 17 or 18.