Method and apparatus for supporting mismatch detection

TECHNICAL FIELD

The present invention relates to communication networks, and in particular to methods and systems for service management that provide mismatch detection support.

BACKGROUND

Communication Error Management (CFM), as described in IEEE Std 802.1 ag - 2007, is a key component of operation, administration, and maintenance for ethernet media. IEEE 802.1ag defines protocols, procedures, and managed objects for the detection, verification and isolation of end-to-end errors. IEEE 802.1ag establishes managed facilities, called Maintenance Associations (MAs), to verify the integrity of a single service by exchanging CFM messages. The scope of MA is defined by its Management Domain (MD), which describes the region of the network where connectivity and operation are managed. Each MA connects two or more Maintenance Association Endpoints (MEPs) and allows Maintenance Association Intermediate Points (MIPs) to support error detection and isolation.

The continuity check protocol is used to detect errors. Each MEP periodically transmits CCMs and tracks CCMs received from other MEPs in the same maintenance association.

Traffic Engineering Provider Backbone Bridging - Traffic Engineering (PBB-TE), as described in IEEE Std 802.1Qay - 2009, was designed to provide full engineering of path traffic in the bridged network. PBB-TE eliminates the need for backbone network equipment to perform learning and flow routing. Instead of using the Multiple Spanning Tree Protocol / Fast Spanning Tree Protocol (MSTP / RSTP) to avoid loops, PBB-TE uses a management plane or an external control plane to create static filtering table entries in component bridges.

PBB-TE is a connection-oriented ethernet technology that uses a statically configured tuple consisting of ESP Destination Address (ESP-DA), ESP Source Address (ESP-SA), and ESP VLAN ID (ESP-VID) to create the PBB- path THESE. The path provided is called the Eternet Switch Path (ESP). Two co-soldered point-to-point ESPs with the same MAC addresses of the Customer Backbone Port (CBP) form a two-way MAC service, which is called a point-to-point Traffic Engineering Service Instance (TESI) service.

PBB-TE supports bi-directional 1: 1 path protection switching. Two TESI point-to-point are provided as TE (TEPG) protecting group. One TESI is configured as "working" TESI and the other as "security" TESI. Under normal conditions, traffic is transmitted on a working TESI. In the event of either a failure of the working TESI or a specific administrative request, the traffic is switched to the security TESI.

Optionally, 1: 1 secured PBB-paths can be configured to enable load sharing. In load sharing mode, the TESIs that are allocated to the TE security group can be reused in many TE security groups allowing distribution of a list of different core network services among a set of interrelated TE security groups. In other words, in load sharing mode, TESI can be a protection TESI in one TE protection group and be a protection or working TESI in another protection group. Each TESI is monitored by an independent MA and each MA has two MEPs. One is located at the CBP proximal end; and the other is located at the CBP of the distal end. When the near-end MEP detects CCM loss, it notifies the far-end MEP by sending CCM with the Remote Defect Indicator (RDI). Both ends are aware of failure (either by losing CCM or receiving a CCM with an RDI tag), so switching protection to TESI security is done at both ends. When the fault is removed, traffic can be switched back to working TESI or can remain in the security TESI according to the configured mode (inverted or non-inverted).

In the states of certain hardware failures and / or misconfigurations, there may be a mismatch between mapping of backbone network services to the appropriate TESI on terminating CBP. To maintain proper network operation, this mismatch should be detected and reported to the network operator. Then the network operator can remove the defect. There are two types of mismatch in 1: 1 bidirectional protection switching:

• Mismatch due to incomplete protection switching; and • Mismatch due to work / protection configuration.

Mismatch due to incomplete protection switching may occur, e.g. if the proximal end does not switch due to hardware failure but sends RDI to the distal end. The distal end switches to security TESI while the proximal end is still in working TESI. Similarly, a mismatch may also occur when the proximal end switches to security TESI, but the distal end does not switch when it receives an RDI.

A mismatch may also occur due to a poor configuration. For example, one end may be configured to send traffic to a working TESI while the other end is configured to send traffic to a security TESI. Similarly, one end can be configured in inverted mode, while the other end is configured in non-inverted mode. In this case, a mismatch occurs when the failure is removed.

PBB-TE supports the protection of the TESI group crossing the shared sequence of Provider Network Ports (PNP). This PNP sequence, along with the intervening Bridge and LAN relays, is called an infrastructure segment or sometimes simply a segment. The TESI Group is protected against communication failure occurring anywhere in the infrastructure segment, including the endpoint PNP. The method of protection does not affect TESI parts outside the segment; that is, the scope of protection is limited to a particular segment. This type of protection is called Infrastructure Segment Security, which is specified in IEEE P802.1Qbf / D0.0.

There are two types of Infrastructure Security Switching (IPS): 1: 1 IPS and M: 1 IPS. In 1: 1 IPS, the working segment and associated hedging segment are to form the infrastructure security group (IPG). WM: 1 IPS additional security segments are provided. Each such additional security segment is called an alternative security segment. The alternative protection segment can assume the role of protection segment if a protection segment communication failure has been detected. M: 1 IPS requires all segments related to IPG to disconnect from each other. Each envisaged Alternative Security Segment has a unique priority of choice in IPG. After detection of a failure related to the security segment, the role of the security segment is taken by the alternative security segment having the highest (numerically lowest) priority and for which no communication failure was detected.

Infrastructure Segment Security PBB-TE also supports load sharing mode in a similar way to TESI security switching, enabling segment linking with more than one IPG. For example, an operator can designate Segment 1 as a working segment for IPG1 and Segment 2 as a hedging segment for IPG1. The operator can simultaneously designate Segment 2 as a working segment for IPG2 and Segment 1 as a Security Segment for IPG2. In this case, the same MA provides Segment 1 monitoring in IPG1 and IPG2.

International patent application WO2009 / 127931 suggests using a traffic field in CCM to indicate traffic status, e.g. whether traffic is transmitted in TESI monitored by CCM. If the traffic field of the received and transmitted CCM MEP does not match the predetermined period of time, a mismatch is detected. However, MEP traffic fields supported in PBB-TE may not be sufficient to detect a defect in mismatch in two-way split-mode PBB-TE 1: 1 path switching or PBB-TE Infrastructure Segment Protection. The traffic field may indicate whether or not there is traffic on a particular TESI or infrastructure segment, but in the case of load sharing, traffic on the infrastructure segment TESI may be associated with several different TE protection groups or infrastructure protection groups.

SUMMARY

The object of the present invention is to provide a method and apparatus for managing services that provide service when a mismatch is detected. The above stated goal is achieved by the method and network node in accordance with independent claims.

The first embodiment provides a method of managing services on a first node of a communication network. The method includes monitoring multiple bi-directional and separate network paths for moving multiple services from the first network node to the second network node. Network paths form a security group associated with the appropriate service or service group. Network path monitoring includes the continuous and periodic sending of Continuity Check Messages (CCMs) on the monitored network path to the second network node. In response to the occurrence of a predetermined event, the indication bit is incorporated into the CCM, which are sent on the monitored network path for the predetermined first period of time after the predetermined event. The indication bit indicates the presence of the mismatch information element in the CCM that contains the indication bit. The mismatch information element contains information that specifies, for each protection group of which the network path is monitored, the traffic status of the working network path, and the security group network paths.

The second embodiment provides a network node for use in a communication network. A network node contains many Operational, Administrative and Management units, configured to monitor multiple two-way and separate network paths for moving many services from a network node to another network node. Network paths form a security group associated with the appropriate service or service group. OAMs are configured to send Continuity Check Messages (CCMs) continuously and periodically on the monitored network path to the second network node. The OAM units are also configured to enable, in response to the occurrence of a predetermined event, the indication bit to CCM, which are sent on the monitored network path for the predetermined first period of time after the predetermined event. The indication bit indicates the presence of the mismatch information element in the CCM that contains the indication bit. The mismatch information element contains information that specifies, for each protection group of which the network path is monitored, the traffic status of the working network path, and the security group network paths.

An advantage of certain embodiments described herein is that they provide improved mismatch detection capabilities in shared load mode.

Another benefit is that the embodiments presented here provide a simple CCM improvement based on existing hardware architecture, with little impact on existing standards.

Another advantage is that some embodiments avoid increasing the complexity of CCM processing by limiting the transmission of the mismatch information element to a limited period of time after the occurrence of a predetermined event that may cause a mismatch. The indication bit that is used to indicate the presence of the mismatch information element in CCM can be generalized to indicate that there is a special TLV attached to the CCM for future CCM extension.

Another invention is that certain embodiments shown herein are suitable for use in PBB-TE as well as security of the PBB-TE infrastructure segment.

Further benefits and features of embodiments of the present invention will become apparent upon reading the following detailed description in connection with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Figures 1a and 1b are schematic block diagrams illustrating the PBB-TE configuration in accordance with an embodiment in a situation of normal operation and mismatch, respectively.

Fig. 2a and Fig. 2b are schematic block diagrams illustrating the security configuration of the PBB-TE infrastructure segment in normal operation and mismatch situations, respectively.

Fig. 3 is a schematic block diagram illustrating the Switch configuration

M Infrastructure Security: 1.

Figures 4a and 4b are schematic block diagrams illustrating a configuration subsection

M: 1 Infrastructure Security Switching in Fig. 3 in a normal operation and mismatch situation according to an embodiment.

Fig. 5 is a flowchart illustrating an embodiment of a service management method that provides mismatch detection support.

Fig. 6 is a flow diagram illustrating an alternative embodiment of a service management method that provides detection detection support in a received CCM.

Fig. 7 is a schematic block diagram illustrating an embodiment of a network node for service management with mismatch detection support.

Fig. 8 is a schematic block diagram illustrating an alternative embodiment of a network node for service management with mismatch detection support.

Figures 9a, 9b and 9c are schematic block diagrams illustrating the CFM header format, CCM Tag field format, and TLV mismatch format in accordance with the exemplary embodiments shown herein.

DETAILED DESCRIPTION

The present invention will now be described in more detail with reference to the accompanying drawings, in which preferred embodiments of the invention are shown. The present invention may, however, be implemented in many other forms and should not be construed as limited to the embodiments detailed herein; instead, these embodiments are provided to make the present disclosure accurate and complete, and will fully reflect the scope of the invention's protection for those skilled in the art. In the drawings, similar reference numbers refer to similar elements.

FIG. 1 illustrates the part of communication network 1 containing the configuration of the Traffic Engineering Provider Backbone Bridging-Traffic Engineering (PBB-TE) for transporting traffic between the distal end (also known as West B-Component) 2, and the proximal end (also known as East BComponent) 3. The further end 2 includes the Customer Backbone Port (CBP) 4 and Provider Network Ports (PNP) 6a and 6b. The proximal end 3 contains CBP 5 and PNP 6c and 6d. There are two separate and two-way network paths illustrated between the proximal 3 and distal end 2 in the form of the first and second Traffic Engineering Service Instance (TESI) 7 and 8. Each TESI is monitored by an independent Maintenance Association MA, and each MA has two MEPs. One is located at CBP 4 distal end; and the other is located at CBP 5 proximal end. Thus, CBP 4 is illustrated to contain MEP 9a associated with the first TESI 7 and MEP 9b associated with the second TESI 8, while CBP 5 is illustrated to include MEP 9c associated with the first TESI 7 and MEP 9d associated with the second TESI 8 Fig. 1a illustrates the split load mode. Traffic related to services 10a, 10b and 10c, which in this example are core network services, is performed on TESI 7 and 8. TESI 7 and 8 form Traffic Engineering security (TE) groups associated with the relevant backbone network services. It is assumed in this example that A, B and C are used as protection group identifiers to reference the respective protection groups associated with the respective core network services 10a, 10b and 10c. In security group A in TE, the first TESI 7 is the working TESI and the second TESI 8 is the protecting TESI.

In security group B in TE, the first TESI 7 is the working TESI and the third TESI (not shown for simplicity reasons) is the protecting TESI and in the security group C in TE, the second TESI 8 is the working TESI and the fourth TESI (not presented for reasons simplifications) is a TESI safeguard. In Fig. 1a, normal operation is illustrated, causing the first TESI 7 to transfer traffic regarding security groups A and B in TE, corresponding to core network services 10a and 10b, respectively, when the second TESI transfers traffic related to security group C in TE, corresponding to core network service 10c .

Each MEP 9a-d periodically transmits Continuity Check Messages (CCM) 11 and tracks CCMs received from other MEPs in the same Maintenance Association. If, e.g., MEP 9b proximal end detects CCM 11 loss, it notifies MEP 9a distal end by sending CCM with a Remote Defect Indicator (RDI). Both ends are aware of a failure (either by loss of CCM or by receiving a CCM with an RDI tag), so switching protection to security TESI is then performed at both ends. Because the first TESI is the working TESI for protection group A in TE and protection group B in TE in this load sharing example, both protection groups A and B should switch to their respective protection TESI. When the failure is resolved, traffic may be switched back to the first TESI 7 or may remain in the protection TESI (s) according to the configured mode (inverted or inverted) of the respective protection groups A and B.

As mentioned above, there are different types of mismatches that may occur in bidirectional 1: 1 protection switching. An example of incomplete protection switching mismatch is described in Figure 1b. In this example, due to some hardware failure, the proximal end 3 does not switch protection group A in TE to protection TESI but sends RDI 14 to distal end 2. The distal end switches to protection TESI for protection group A in TE, while the near end is still in working TESI. Similarly, mismatch can also occur when the proximal end 3 switches to security TESI but the distal end 2 does not switch when it receives an RDI. It is desirable to detect and report any mismatch to the operator or the NMS Network Management System as soon as possible.

Mismatch can also happen due to incorrect configuration. For example, one end is configured to send traffic to a working TESI, while the other end is configured to send traffic to a security TESI. Another situation where a mismatch may arise is when one end is configured as inverted mode, while the other end is configured as non-inverted mode. Mismatch occurs when the failure is removed.

If the MEP 9a-d support the CCM traffic field mentioned above, the mismatch can be detected in non-split operation mode. The traffic field can be one of four reserved bits in the CCM tag field. This bit indicates the status of the traffic, i.e. whether the traffic is or is not transmitted in the TESI monitored by CCM. Mismatch is detected in one of the MEPs when the traffic field of the transmitted CCMs and received CCMs do not match over a period of time (e.g. 50 ms or longer). The mismatch error is cleared when the corresponding MEP receives the first CCM that indicates the same traffic field as the CCM transmitted from the MEP.

Figs. 2a and 2b are schematic block diagrams illustrating Switching 1: 1 Infrastructure Security (IPS) where the segment is terminated on the PNP ports of Backbone Core Bridges (BCB) 22. BCB 22 are called Segment Endpoint Bridges (SEB) and Bridge 23 inside the segment is called the Segment Intermediate Bridge (SIB). BCB 21 outside the segment and IB Backbone Edge Bridges (IP-BEB) 20 are also illustrated in Figs. 2a and 2b. TESI 24 and TESI 25 intersect the working segment 26 in a normal operation situation as illustrated in Fig. 2a. Safety segment 27 is provided to allow switching of TESI 24, 25 protection. Working segment 26 and protection segment 27 are disconnected, but end in the same pair of SEB 22. Working segment 26 and associated protection segment 27 form an Infrastructure Protection Group (IPG).

After detecting communication failure on a working segment 26 or as a result of an administrative command,

SEB 22 directs TESI 24, 25 associated with the working segment 26 to the securing segment 27 as shown in Fig. 2b.

An example of IPS M: 1 is shown in Fig. 3. The elements illustrated in Fig. 3 correspond to the elements illustrated in Figs. 2a and 2b with the addition of alternative securing segments 28 and 29. Each alternative securing segment provided has priority of choice in IPG. Upon detection of a failure related to the protection segment 27, the role of the protection segment is assumed by the alternative protection segment 28 or 29 having the highest (numerically lowest) priority and for which no communication failure has been detected.

The inventors have realized that the aforementioned traffic field supported in MEP PBB-TE may not be sufficient for detecting mismatches in two-way load sharing switching of PBB-TE 1: 1 path protection or PBB-TE Infrastructure Segment Protection.

In the bi-directional switching mode of the PBB-TE 1: 1 path protection, the TESI assigned to the TE protection group can be reused in other TE protection groups. This makes the application of the traffic field insufficient to detect mismatch defects because it can only indicate whether there is traffic on a specific TESI, and the presence or absence of traffic on the TESI that are shared in a set of TE protecting groups is not directly related to the proper operation of the security switching mechanisms. The same applies to the load sharing mode of the PBB-TE Infrastructure Segment Security because the traffic field can only determine whether there is traffic on a particular Segment but does not associate this traffic with the IPG to which the traffic belongs.

For example, as in Figure 1a, in normal operation, there is always traffic through the first TESI 7 and the second TESI 8, so that the traffic field will always be set by the MA monitoring these TESI. Therefore, the mismatch situation described above and illustrated in Fig. 1b cannot be detected by MA only by monitoring the CCM 11 traffic field on TESI 7 and 8, because the traffic fields from CCM 11 are always set in two directions. More specifically in Fig. 1b, the CCM traffic field in the first TESI 7 is always set because the first TESI 7 is still the working TESI protecting group B in TE, and the CCM traffic field in the second TESI 8 is always set because the second TESI 8 is still working TESI protecting group C in TE .

Figures 4a and 4b illustrate an example of the load sharing mode of the Security Segment of the PBB-TE Infrastructure in normal operation and mismatch situations, respectively. In a normal operating situation as shown in Fig. 4a, the IPG D, which includes TESI 24 and 25, intersects the segment 26, which is the working segment IPG D. The IPG D is protected by its own security segment, which is segment 27. IPG E, which contains TESI 41 and 42, intersects segment 27, which is the working segment IPG E. IPG E is protected by segment 26, which is the security segment IPG E. Therefore, in normal operation, because there is always traffic through segment 26 and 27, the traffic field will always be set by MEP 43a, 43b, 43c and 43d monitoring segments 26, 27.

Now, let's assume that there is an administrative command that dictates that all TESI 24, 25 IPG D in segment 26 should be switched to the security segment, i.e. to segment 27. Due to a configuration error, only TESI 25 is switched to the IPG D security segment and TESI 24 still remains in the working segment IPG D as illustrated in Fig. 4b. Accordingly, there is a mismatch here in this scenario because there will be IPG D traffic on both the working TESI and the security TESI. However, traffic field monitoring in segment monitor MAs cannot detect a mismatch because traffic fields from CCM are always set in both directions.

In M: 1 Infrastructure Security, both ends must have the same order of priority for alternative hedging segments to avoid possible mismatches. If there is a configuration error regarding a priority order, the configuration error cannot be detected based on previously known mismatch detection mechanisms such as the motion field.

For example, as in Figs. 4a and 4b, suppose alternative protection segments 28 and 29 are configured for IPG D. Let's also assume that priority order is configured as 0 for segment 28 and 1 for segment 29 in SEB 22 at one end, and at SEB 22 at the other end, the priority row is configured as 1 for segment 28 and 0 for segment 29. If there is a communication failure on the protection segment (segment 27) IPG D, SEB 22 will select segment 28 as the protection segment at one end and SEB 22 at the other end will select segment 29 as the protection segment. This configuration error will not be detected until there is a communication failure on the working segment (segment 26). When SEB 22 at one end switches the associated TESI to segment 28 and SEB 22 at the other end switches the associated TESI to segment 29, a matching error occurs. However, as indicated in previous examples, it may not be possible to detect this mismatch if the PBB-TE Infrastructure Segment Protection is in load sharing mode.

As illustrated by the above examples, the traffic field is insufficient to detect a mismatch in load sharing mode for bidirectional 1: 1 PBB-TE path protection or PBB-TE Infrastructure Segment Protection. Therefore, it would be desirable to have a different mechanism, preferably based on existing bridge architecture, to monitor working / security units that will allow immediate reporting of mismatches to operators.

The embodiments described in detail below use the CCM bit as the indication bit, which indicates a mismatch information element in the CCM. The indication bit may e.g. be a bit in the CCM tag field and the mismatch information element may e.g. be a type-length-value (TLV) of the mismatch. The mismatch information element is defined to determine the traffic status for different security groups in TE for a specific TESI or different infrastructure security groups for a specific segment. Other configuration parameters can also be optionally included to coordinate both ends.

In accordance with the embodiments described herein, the indication bit is set in response to the occurrence of the predetermined event and for a configurable period of time (referred to herein as the first period of time) after the occurrence of the predetermined event. In some exemplary embodiments, the indication bit is set only when a transition to a new state occurs in the protection switching state device and only for a limited period of time (i.e. first period of time) after the transition to avoid slowing down normal CCM processing.

Fig. 9a is a schematic block diagram of the CFM data unit (PDU) header format including MD level field, version, OpCode, markers 91 and the first TLV Offset. Fig. 9b is a schematic block diagram of a CCM 91 PDU marker field in accordance with an exemplary embodiment. In this exemplary embodiment, the bit in the tag field 91 is used as the indication bit 92 to indicate whether the mismatch information element is included in the CCM. According to the current standard, there are a plurality of reserved bits in the tag field 91 and in accordance with this exemplary embodiment, one of these reserved bits is used as indication bit 92.

As mentioned above, the mismatch information element should be defined to specify the traffic status for different TE protection groups (TEPG) for a specific TESI or different Infrastructure Protection Groups (IPG) for a specific Segment. The mismatch information element should, in accordance with some embodiments, be added to the CCM only when the state device starts or when an event occurs that causes the traffic to switch from one path to another, in other words in connection with the state transition in the state device. The mismatch information element may be added to CCMs that monitor the corresponding network path for a limited period of time (i.e. first period of time) to avoid slowing down normal CCM processing. There is one set of protection switch state device per protection group on each bridge that ends the protection bridge. Accordingly, the state device is located in the nodes / bridges 2, 3 and 22 of Figs. 1-4 described above. In IEEE standards, a status device typically has states such as

Initialization, Failure of the Working TESI / Segment, Failure of the Security TESI / Segment etc. Accordingly, the transition of state generally assumes that something is happening with the network path or that the network operator wants to change the traffic path. If there are no failures or reconfiguration by the administrative command, there will be no change of state. When the status device starts or a new state in the status device is going to start, for example, STARTING -> Work or Work -> Protection, a mismatch information element can be added to the CCM and the corresponding indication bit is set. The reason is that a mismatch error usually occurs when a state transition occurs. Thus, there is generally no need to monitor mismatches with the mismatch information element at all times. Instead, it is usually sufficient to check whether there is a mismatch in incomplete protection switching or a configuration mismatch as soon as the state transition occurs. There is also no need to check CCM with the mismatch information element all the time after a change of state. A limited period of time (referred to herein as the first period of time) can be configured, which is considered appropriate and sufficient to detect any mismatch in connection with the transition of the state. This first period of time may e.g. be 50ms or longer and may be monitored by a mismatch information clock.

The format of the exemplary embodiment of the mismatch information element 93 is illustrated in Fig. 9c. The mismatch information element 93 of Fig. 9c is a TLV mismatch defined on the basis of the data structure in the document of the IEEE Std 802.1 Qay - 2009 standard or the IEEE P802.1Qbf / D0.0 standard to facilitate modification of these standards to comply with the embodiments described herein.

According to the modified version of the IEEE 802.1Qay TLV standard, the mismatch 93 houses a list of traffic engineering security groups (TEPGs) to which TESI monitored by CCM is allocated. Each entry in the list contains the following items related to TEPG:

• TEPG identity • Traffic status for a working TESI in TEPG, in other words, whether a working TESI is active for traffic from this TEPG. If active, move status = 1, if inactive, move status = 0.

• traffic status for the security TESI in TEPG, in other words, whether this security TESI is active for traffic from this TEPG.

If active, move status = 1, if inactive, move status = 0.

The TEPG identity should be unique within shared security groups and both TESI endpoints should share the same understanding of the identity of shared security groups. One possible thought is to use a combination of working TE-SID and security TE-SID for the unique identification of one TEPG, but any other identifier meeting the above condition is suitable.

In Fig. 1a, mismatch information elements 13a, 13b, 13c and 13d are shown to schematically illustrate the content of mismatch information elements that will be transmitted in CCM from the corresponding MEP 9a-d in the normal operation situation of the exemplary configuration illustrated in Fig. 1a. For simplicity reasons, the TEPG identities are represented here by letters.

According to the modified version of the IEEE 802.1Qbf TLV standard, the mismatch 93 houses the IPG list to which the segment monitored by CCM is assigned. Each entry in the list contains the following items related to IPG:

• IPG identity • Traffic status for a working segment in IPPG, in other words, whether this working segment is active for traffic from this IPG. If it is active, traffic status = 1, if it is inactive, traffic status = 0. • Traffic status for the security segment in IPG, in other words, whether this security segment is active for traffic from this IPG.

If it is active, move status = 1, if it is inactive, move status = 0.

The IPG identity should be unique within shared security groups and both SEBs should share the same understanding of the identity of shared security groups. One possible thought is to use a combination of the Working MAID Segment and Security MAID Segment for the unique identification of one IPG, but any other identifier that meets the above condition is appropriate.

In Fig. 4a, mismatch information elements 44a, 44b, 44c and 44d are shown to schematically illustrate the content of the mismatch information elements that will be transmitted in CCM from the respective MEP 43a-d in a normal operation situation of the exemplary configuration illustrated in Fig. 4a. For simplicity reasons, IPG identities are represented here by letters.

According to the exemplary embodiments, whenever CCMs are sent by MEP, the following operations can be performed:

• MEP checks if there is a state device transition or if the TLV mismatch counter has expired for all shared TEPGs or shared IPGs associated with MEPs. If a state transition occurs or the TLV mismatch counter still works for any of these MEP-related TEPGs or IPGs, MEP performs the following

a. Sets the protocol version in CCM to version 2. (In version 1, reserved bits in tag field 91 are ignored.)

b. Sets "Display Field" 92 in CCM to "true".

c. Adds TLV mismatch of adequate value to CCM.

TLV "Mismatches" is built on the basis of information configured by operators. Mismatch is detected if • Both, Traffic Status for Working and Traffic Status for Safety Field are the same for a specific TEPG or IPG.

Whenever CCMs are received by the MEP, the following operation can be performed by the corresponding MEP:

• Compare each received TLV mismatch with its own current TLV MEP mismatch. If it is different for a period of time (here referred to as the second period of time), e.g. 50 ms, a mismatch error is declared.

For example, the mismatch situation illustrated and described with reference to Fig. 1b can be detected by mismatch information elements 13a-d, which in Fig. 1b are illustrated with content corresponding to the mismatch situation. In this case, the mismatch will be detected when one MEP receives the mismatch information elements and finds that the received mismatch information elements are different from the transmitted own MEP mismatch information elements during the second period of time. MEP 9a may, for example, detect a mismatch by comparing the mismatch information element 13c received in the CCM with MEP 9c with the mismatch information element 13a which MEP 9c transmits on TESI 7. The comparison shows the different traffic status for the working and safety TESI TEPG A, which indicates a mismatch. Mismatch can also be detected by appropriate comparisons in MEP 9b, 9c and 9d.

An exemplary mismatch situation illustrated and described with reference to Fig. 4b can be detected by mismatch information elements 44a-d, which in Fig. 4b are illustrated with content corresponding to the mismatch situation. In this case, the mismatch will be detected in MEP 43a-d because for IPG D, both the working segment and the safety segment are active for traffic as indicated by the traffic status for IPG D in the mismatch information elements 44a-d. Thus, this type of configuration mismatch can be detected.

If there is a priority order configuration error for alternative security segments in Infrastructure Security M: 1, a mismatch can be detected when there is a communication failure on the original security segment. If the IPG identity contains

MAID of the security segment, this particular IPG identity will be different between the mismatch information element at both ends

The suggested indication bit can be used whenever CCM needs to be checked more thoroughly. In addition to indicating that there is a mismatch information element included in CCM, the indication bit may be extended to indicate that there is a special information element (e.g. TLV) attached to CCM for future CCM extension.

Fig. 5 is a flowchart illustrating an exemplary embodiment of a service management method in a network node such as one of the illustrated bridges / nodes 2, 3 or 22. The method includes monitoring multiple bi-directional and separate network paths carrying multiple services from a network node to another network node. The network paths may be, for example, TESI carrying many backbone services or infrastructure segments hosting many TESIs. Network paths form one or more security groups associated with the appropriate service or service group. Network path monitoring includes periodic CCM transmission on the monitored network path. More specifically and as illustrated in Fig. 5 it is determined in step 51 whether it is CCM sending time. If this is the CCM sending time, it is examined whether a predetermined event has occurred and if the time from such predetermined event was shorter than the predetermined time t, step 52. The predetermined event may e.g. be a state transition in the protection switching state device and the time t (referred to above as the first period of time) may be e.g. 50 ms as discussed above. If the determination in step 52 is confirming, the indication bit and the mismatch information element are to be included in CCM, step 53, otherwise CCM is to be sent without the indication bit and the mismatch information element in step 56. As discussed above, the mismatch information element contains information that specifies for each security group of which the network path is monitored, the network status of the working network path, and the security network paths. In optional step 54, the sent CCM mismatch information element can be examined to determine if there is a conflicting status of the working path and the securing path of any securing group included in the mismatch information element. If such conflicting traffic status is detected, the operator or NMS is notified that a mismatch has been detected in step 55. CCM is sent in step 56. Step 56 can also be performed before optional steps 54 and 55.

An exemplary embodiment of a service management method at a network node may, in addition to CCM transmissions as illustrated in Fig. 5, also include monitoring received CCMs as illustrated in Fig. 6. At step 61, CCM is received on the monitored network path. At step 62, it is examined whether the received CCM contains an indication bit that indicates the presence of a mismatch information element in the CCM. If the received CCM contains a mismatch information element, then the mismatch information element is read and compared to the mismatch information element corresponding to the CCM sent to the same network path. The corresponding CCM sent can e.g. be CCM that was sent last before receiving the received CCM or the first CCM that is sent after receiving the received CCM. In step 64, it is determined whether the compared mismatch information elements are different, e.g. in terms of traffic status of any working or security network path or in terms of security group identity (see above discussion on how to detect mismatch in the configured priority for alternative security segments). If the mismatch information elements being compared are different, the operator or NMS is notified of the mismatch detected in step 65.

Fig. 7 is a schematic block diagram of an exemplary embodiment 70 of a network node in which the method illustrated in Figs. 5 and 6 may be performed. Network node 70 includes processing circuits 71 and a plurality of network ports 72 for receiving and transmitting messages to multiple network paths. Processing circuits 71 contain a number of Operating, Administrative and Management Units (OAMs) 73. The above-mentioned MEP 9a-di 43a-d are examples of OAMs. OAM units are configured to perform steps 51-56 of Fig. 5 and steps 61-65 of Fig. 6. To this end, the units

OAM 73 may include the CCM 74 control sub-module for controlling creation, transmission and receiving

CCM, and mismatch checking sub-module 75 configured to detect mismatches by examining mismatch information elements in sent and / or received CCMs.

Fig. 8 is a schematic block diagram of another exemplary embodiment 80 of a network node in which the method illustrated in Figs. 5 and 6 can be performed. Fig. 8 can be an alternative description of the exemplary embodiments shown in Fig. 7. Network node 80 includes ports networks 72 to receive and transmit messages to multiple network paths. The network node 80 also includes an input unit 81 that is adapted to receive messages from network paths and an output unit to send messages to network paths. The input unit 81 and the output unit 82 can be integrated in the equipment of the network node 80. The network node 80 is also equipped with a CPU 83, which may be a single unit or may be composed of several units configured to perform the steps of the procedures described herein. At least one computer program 84 is included in UE 22. The computer program 84 may be embodied in the form of non-volatile or non-volatile memory, e.g., EEPROM, flash memory or disk drive. Computer program 84 includes computer program sub-modules. FIG. 8 shows CCM transmission sub-module 85 for controlling the creation and transmission of CCM on monitored network paths, mismatch information element sub-module 86 for generating mismatch information elements to include mismatch information elements in CCM, mismatch check module 87 for detecting mismatch by detecting conflicting traffic status in mismatch information elements in CCM sent, and a mismatch check module 88 for detecting mismatches by comparing mismatch information elements in received and transmitted CCMs. Sub-modules 85-88 generally perform steps 51-56 of the flow chart of Fig. 5 and steps 61-65 of the flow chart of Fig. 6. In other words, when different sub-modules 85-88 work on the CPU 83, then the network node performs steps 51-56 of Fig. 5 and steps 61-65 of Fig. 6. Sub-modules 85-88 will generally be implemented in software, although implementations may be fully or partially in the firmware, hardware or combinations thereof.

In the drawings and description, typical preferred embodiments of the invention are disclosed and, although certain terms are used, they are used only in a general and descriptive sense, and not for the purpose of limitation, and the scope of the invention is set out in the appended claims.

"ATENTOWA" BELLEPAT "LAW OFFICE

Izabela Szychiilska-Hawranek ul Słowackiego 44, 37-700 Prziioł.śl tek (016) 7o2-37-77 fax: (016) 075-02-87 mobile phone, (0608) 503-081 e-maii <a href="mailto:tellepat@op.pl">tellepat@op.pl</a> NIP: 795-207-16-72 REGON: 1803505: 6

Proxy:

<img file="PL2507944T3_D0001.tif" />