WO2008132203A2

WO2008132203A2 - Recovering from a failure in a communications network

Info

Publication number: WO2008132203A2
Application number: PCT/EP2008/055180
Authority: WO
Inventors: Riccardo Martinotti; Andrea Corti; Raoul Fiorone
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2007-04-25
Filing date: 2008-04-28
Publication date: 2008-11-06
Also published as: WO2008132203A8; GB2448711A; GB0707915D0; WO2008132203A3

Abstract

A method of recovering from a failure of a link connecting a client to a node or of a node in a communications network using a dual homing protection and comprising a plurality of nodes. One of said nodes is connected to another network. A first node and a second node are connected to the client, and one of the ports related to the links connecting the client with the nodes is in an active state and the other is in a stand-by state. The method comprises detecting the failure (502), changing (504) both ports status. In response to the status change, sending, (506) to the node connected to the other network, a request to purge its MAC address table, purging (508) the MAC address table and flooding (510) nodes of the communications network in order to fill in the purged MAC address table with updated information, directing (512) traffic to and from the client via the link having the related port in the active state.

Description

RECOVERING FROM A FAILURE IN A COMMUNICATIONS NETWORK

Field of the Invention

The present invention relates to telecommunications networks, in general, and in particular to recovering from a failure in a communications network using dual homing protection for connection of a client to the network.

Background of the Invention

Dual homing protection for the client equipment in a communications network is a scenario that is gaining high interest for its characteristics of reliability and resilience. It is more complicated than a single homing protection since it involves two different nodes in the communications network and no standard Link Aggregation can be used. A Metro Multi-Protocol Label Switching (MPLS) network is an example only, but the problem described below exists irrespective of the actual technology used in the Metro transport network: MPLS, Provider Bridge, Q-in-Q, PBB (Provider Backbone Bridges), PBB-TE (Provider Backbone Bridges - Traffic Engineering), Ethernet, Synchronous Digital Hierarchy (SDH) or other.

The use of an instance of a Spanning Tree Protocol (STP) or a Rapid Spanning Tree Protocol (RSTP) only for dual homing protection purposes involves some potential issues, which have to do with the overall network efficiency, and the way the underlying Layer 2 service is provided. The same issues may apply to alternative protocols which share with STP and RSTP the same functional behaviour (they may be proprietary solutions using the same basic concepts).

In FIG. 1 an example of normal operation conditions is illustrated. Taking into account the two links in dual homing (i.e. 102 and 104), assuming that STP is implemented, the port on node 110 related to link 104 is in Blocking State and the port on node 108 related to link 102 is in Forwarding State. In an MPLS Provider Network 100, this means, for example, that the two Label Switched Paths (LSPs) 116, 118 on the left side of the network, in this case a Metro ring for the sake of simplicity, are used to carry the traffic related to the protected client 106 in both directions. This is the normal state.

If a failure 202 condition occurs to the customer link 102 related to port in Forwarding State on node 108 (it can be a fibre cut, a client port or card failure or a port or card failure on the Metro node) the STP or the RSTP detects the problem and acts consequently. In the case of RSTP the reaction time is very short, while it is longer in case of a plain STP. The situation is shown in FIG. 2, where the transition phase is illustrated. By transition phase it is meant the situation where the STP or RSTP puts in Forwarding State the port that was in Blocking State, and therefore the upstream traffic is carried by an LSP 122 on the right side of the Metro ring. In this example of hubbed traffic patterns, which is typical of residential applications, the head-end node 112 has no other way to realise that something happened except when it starts receiving traffic sent by the client 106 from another line card. Once traffic is received from the client, the Media Access Control address (MAC address) learning mechanism is such that the head-end node 112 starts sending traffic downstream accordingly.

The mechanism described is potentially subject to problems, which are dependent upon the nature of the traffic, and whose duration is quite unpredictable. In fact, when the traffic pattern is strongly mono-directional (from the head-end node to the client), the head-end node has no way to realise that something has changed in the network if it does not receive any packets in the upstream direction (which are going to feed the MAC learning mechanism). This may lead to a significant traffic failure on the network, since the traffic that is sent downstream in FIG. 2 will simply be lost (because sent out from the wrong port by the head-end node 112).

The other way in which the head-end node 112 can react to the change is when the ageing mechanism deletes its MAC address entries related to the specific client, and therefore a new MAC learning phase is started by means of flooding. The problem with this solution is that a typical ageing time for MAC address entries is 300 s (i.e. 5 minutes!). Possible remedies to this issue include participation of the head-end node in the STP or RSTP mechanism. However, the head-end node running and participating in the STP or RSTP is heavy and unpractical, for a series of reasons, such as the necessity to potentially run many instances of STP or RSTP in the head-end node (which is a big problem in case of many clients protected in dual homing) and the fact that the STP or RSTP would have to provide a control plane functionality for the MPLS network (or, in general, for the Provider Network, whatever technology is adopted). In fact, in this way STP or RSTP would be run inside the Provider Network determining which ports need to be used in the trunk part of the network, thus actually improperly acting like a part of the Provider's control plane.

Another method known in the art is notifying the topology change to the head-end node and requiring purging the MAC address entries related to the specific physical ports involved in the change driven by STP or RSTP. This is done using standard methods, like those made available by Label Distribution Protocol (LDP). The disadvantage of this solution is that it requires use of a complete protocol, which may not be needed for other purposes, and it can cope only with client link failures.

Hence, an improved method of recovering from a failure in a communications network using dual homing protection would be advantageous and in particular one that is simple and can equally manage recovering from client link or port failure and from network node failure.

Summary of the Invention Accordingly, the invention seeks to preferably mitigate, alleviate or eliminate one or more of the disadvantages mentioned above singly or in any combination.

According to the first aspect of the present invention a method of recovering from a failure of a link connecting a client to a node or from a failure of a node in a communications network using dual homing protection is disclosed. Said communications network comprises a plurality of nodes and at least one of said nodes is connected to another network, a first node, of said plurality of nodes, is connected to the client and a second node, of said plurality of nodes, is also connected to the client. One of the ports related to the links connecting the client with the nodes is in an active state and the other port is in a stand-by state. The method comprises the following steps: detecting the failure, changing the port status from active to stand-by and the other port from stand-by to active. In response to the change of the status, from stand-by to active, the node in the active state sends to the node connected to the another network a request to purge its MAC address table. In the next step, in response to said request, the node connected to the another network purges its MAC address table and then performs flooding in order to fill in the purged MAC address table with updated information. Once the MAC address table is updated traffic to and from the client is directed via the link having the related port in the active state.

Further features of the present invention are as claimed in the dependent claims.

The present invention beneficially allows for a very fast, reliable and predictable recovery time for the Layer 2 traffic being exchanged by clients or client networks, which are connected in dual homing to a transport network made available by a provider (Provider Network), in the event of a failure to the client traffic. In fact, the present invention can be beneficially effective in case of both link failure towards the client (or port or card failure in the client equipment) and failure of one of the provider network nodes involved in the dual homing protection. The present invention is beneficially independent of any traffic patterns or characteristics, and therefore the time it takes to be effective is predictable. The present invention is also applicable to various technologies in which the Provider Network can be implemented, since it only requires very simple and minimal information to be sent to the node or the nodes which need to purge their MAC address tables related to the client that has experienced the failure. The present invention also applies to cases where the dual homing protection is realised with protocols or methods other than STP and RSTP, whose basic mechanism relies on putting ports of the client equipment and/or of the network node in an active state or in a stand-by state. Brief description of the drawings

The present invention will be understood and appreciated more fully from the following detailed description taken in conjunction with the drawings in which:

FIG. 1 is a diagram illustrating a ringed communications network with dual homing protection in normal operation;

FIG. 2 is a diagram illustrating a ringed communications network with dual homing protection in with a failure developed in a client link;

FIG. 3 is a diagram illustrating a ringed communications network with dual homing protection in with a failure developed in a network node;

FIG. 4 is a diagram illustrating a ringed communications network with dual homing protection recovered from the failure;

FIG. 5 is a flowchart illustrating a method of recovering from a failure in a ringed communications network with dual homing protection in one embodiment of the present invention.

Description of embodiments of the invention

The present invention is discussed herein below in the context of a Multi-Protocol Label Switching provider network. However, it should be understood that it is not limited to MPLS networks, but also applies to other transport network technologies, e.g. T-MPLS (Transport MPLS), Provider Bridge, Q-in-Q, PBB (Provider Backbone Bridges), PBB-TE (Provider Backbone Bridges - Traffic Engineering), Ethernet, SDH and other.

With reference to FIG. 1 and FIG. 5 a method of recovering from a failure in a ringed network using dual homing protection towards the clients is presented. The ring topology has been chosen for its simplicity of description. In normal operating conditions one of the links towards the client, for example, a first link 102 connecting the client 106 with a first node 108 has the related port on node 108 in forwarding (i.e. active) state. The second link 104 connecting the client 106 with a second node 110 has the related port on node 110 in blocking state (i.e. stand-by, which term also covers a fail status). This means that all the traffic between the client and the network passes through the link whose ports are active, which is the first link 102, and the first node 108 connected to this link. If a fault develops in the first link 102 or in the first node 108 the fault is detected, in a preferred embodiment, by a Rapid Spanning Tree Protocol run by the client 106 and at least one of the nodes 108, 110. It must be noted that in the case of a link failure both nodes 108 and 110 can participate together with the client 106 in the RSTP procedure. If, however, it is the first network node 108 that failed, the RSTP procedure is carried out by the client 106 and the second network node 110.

In one embodiment the communications network 100 is a transport network made available by a provider and also known as a Provider Network.

The failure can be detected based on logic criteria or based on physical criteria. The physical criteria refer to detection of lack of connection on a physical layer (i.e. the link is down). Operation, Administration and Maintenance (OAM) messages or RSTP Bridge Protocol Data Unit that can be (in case of OAM) or are periodically sent between connected ports can be used to detect the failure. If such message is not received on a particular port of the client or the network node for n (typically three) consecutive times it indicates a failure on either the link connected to these ports or a device connected to said link. This is an example of detection of a failure based on logical criteria. The failure 202 that this invention is designed to cope with can develop in the link 102 connecting the client 106 to the node (this includes a fibre cut, a client port or card failure or a port or card failure on the Provider Network node), as illustrated in FIG. 2 or the failure may develop, 302, in the network node 108, as illustrated in FIG. 3.

Once the failure is detected the RSTP instances change 504 the status of the port related to the first link 102 from forwarding to discarding and the status of the port related to the second link 104 from discarding to forwarding. In response to the change of the status ot the ports related to links the node connected to the port related to link in forwarding state (i.e. the second node 110 connected to the second link 104) sends 506 to the node 112 connected to another network 114 a request to purge MAC address table of said node 112 connected to another network 114. In one embodiment the node 112 is connected to another part of the same client network rather than to another network 114. In yet another embodiment there may be more than one node connected to another network in the Provider Network 100.

In an embodiment of residential application the node 112 connected to another network 114 is called a head-end node and this is the node that connects the provider network to IP network (e.g. the Internet) and it is the head-end node 112 that is requested to purge its MAC address table. Please note that more complex network scenarios can actually apply where there are two head-end nodes. In this case both head-end nodes need to be required to purge their MAC address tables. In an alternative embodiment of a commercial application (e.g. corporate network based on Layer 2 Virtual Private Network) the request to purge MAC address table is sent 506 to all network nodes operating in said Virtual Private Network (VPN).

In the next step the MAC address table of the head-end node 112 is purged 508 in response to said request (residential application) and in the embodiment with the VPN application the MAC address tables of all network nodes operating in said VPN are purged.

In a preferred embodiment, in the step of purging 508 the MAC address table in the head-end node 112, only the entries related to the client 106 affected by the failure are deleted.

Because after deletion of the entries of the MAC address table, which are related to the client node 106, the head-end node will not know where to send the traffic coming from the other network 114 and whose destination is the client node 106 the head-end node 112 starts a learning phase by performing flooding 510. In the operation of flooding 510 the head-end node 112 multicasts the traffic for which it does not know what output port to use to reach its destination towards the nodes of the network involved in the same services, so that once it gets the related upstream traffic from one of its ports, the relevant entries can be inserted in the MAC address table. Same is applicable to all metro nodes 108, 110, 112 that have their MAC address tables purged in the case of Virtual Private Network.

In a preferred embodiment the flooding 510 is performed by the head-end node or the nodes operating in Virtual Private Network only when there is traffic to be sent to MAC addresses which are not in the MAC address table (included all those relevant to client 106).

Once the learning phase has been completed and the head-end node 112 (in the case of residential application) or the metro nodes 110 - 112 (in the case of VPN application) have their MAC address tables filled in with updated information the traffic 120, 122 to and from the client is directed 512 via the link having the related port in forwarding status, which is the situation illustrated in FIG. 4.

In the presented embodiment a Rapid Spanning Tree Protocol was used as an example. It is, however, equally possible to use other mechanisms like Spanning Tree Protocol (STP) or, even proprietary protocols, for the control of the dual homing protection scheme. The terminology used in Spanning Tree Protocol is slightly different and the active state of a port is known as "forwarding state" and the stand-by state of a port is known as "blocking state". The application of STP instead of RSTP should be clear for a person skilled in the art based on the description of embodiments given above.

Claims

1. A method of recovering from a failure of a link (102, 104) connecting a client (106) to a node (108, 110) or from a failure of a node (108, 110) in a communications network (100) using dual homing protection, said network (100) comprising a plurality of nodes (108 - 112) and at least one of said nodes (112) is connected to another network (114), a first node (108), of said plurality of nodes, is connected to the client (106) and a second node (110), of said plurality of nodes, is connected to the client (106), wherein one of the ports related to the links (102, 104) connecting the client (106) with the nodes (108, 110) is in an active state and the other port is in a stand-by state, the method comprises: a) detecting the failure (502); b) changing (504) the port status from active to stand-by and the other port from stand-by to active; c) in response to the change of the status from stand-by to active, sending (506) to the node connected to the another network (114), by the node whose port is in the active state, a request to purge its MAC address table; d) purging (508) the MAC address table of the node connected to the another network (114) in response to said request and performing flooding (510) in order to fill in the purged MAC address table with updated information; e) directing (512) traffic to and from the client (106) via the link having the related port in the active state.

2. The method according to claim 1, wherein in the step of purging (508) the MAC address table in the node connected to the another network (114) the entries related to the client (106) affected by the failure are deleted.

3. The method according to any one of preceding claims, wherein for the nodes operating in a Virtual Private Network the request to purge a MAC address table is sent (506) to every node operating in said Virtual Private Network.

4. The method according to any one of preceding claims, wherein the steps of detection (502) of the failure and changing the port status is carried out according to a Spanning Tree Protocol or a Rapid Spanning Tree Protocol.

5. The method according to claim 4, wherein the procedure according to Spanning Tree Protocol or a Rapid Spanning Tree Protocol is performed by the client (106) and at least one of the nodes (108, 110) connected to the client (106).

6. The method according to any one of preceding claims, wherein the flooding (510) is performed by the node connected to the another network (114) when there is traffic to be sent to the client.

7. The method according to claim 3, wherein the flooding (510) is performed by all the nodes operating in the Virtual Private Network.

8. The method according to claim 1, where the communications network (100) can be implemented in MPLS, T-MPLS, Provider Bridge, PBB, PBB-TE, Ethernet, SDH or other technology.

9. A communications network (100) using dual homing protection adapted to carry out recovery from a failure of a link (102, 104) connecting a client (106) to a node (108, 110) or from a failure of a node (108, 110), wherein the recovery is carried out according to the method of any one of claims 1 - 8.