WO2014134806A1

WO2014134806A1 - Method and device for protection switching of ethernet ring

Info

Publication number: WO2014134806A1
Application number: PCT/CN2013/072270
Authority: WO
Inventors: Song YUAN; Ziquan PAN; Giovanni MUMOLO; Jiang He
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2013-03-07
Filing date: 2013-03-07
Publication date: 2014-09-12

Abstract

A method in an Ethernet ring node for protection switching of an Ethernet ring is provided, said method comprising : generating (101) one or more fake Ethernet packets in response to a ring topology change; and sending out (102) said one or more fake Ethernet packets to its neighbor ring nodes over the Ethernet ring, wherein each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to said ring node. Also, a method in an Ethernet ring node for protection switching of an Ethernet ring is provided, said method comprising : receiving (201) one or more fake Ethernet packets generated by a second ring node in said Ethernet ring where each one of the fake Ethernet packets contains one source MAC address learnt from client subnets attached to the second ring node; learning (202) one or more source MAC addresses from the received one or more fake Ethernet packets; and forwarding (203) the received one or more fake Ethernet packets over the Ethernet ring.

Description

METHOD AND DEVICE FOR PROTECTION SWITCHING OF ETHERNET RING

Technical Field

The present invention relates generally to Ethernet technology, and more particularly, to method and device for protection switching in Ethernet ring.

Background

Nowadays, more and more operators deploy Ethernet rings in access networks and metro networks. Several protection mechanisms for the Ethernet ring, including Ethernet Ring Protection (ERP) and Rapid Ring Protection Protocol (RRPP), are being used widely, where efforts are made to provide protection for Ethernet traffic in a ring topology, while ensuring that no loops are within the ring at the Ethernet layer.

Fig.l is a typical Ethernet ring composed of six switches, where ERP switching as specified in ITU-T G8032 may be implemented. Typically, each Ethernet ring node is connected to adjacent Ethernet ring nodes participating in the same Ethernet Ring, using two independent links. A ring link is bounded by two adjacent Ethernet ring nodes, and a port for a ring link is called a ring port.

In ERP switching mechanism, loop avoidance in an Ethernet Ring is achieved by guaranteeing that, at any time, traffic may flow on all but one of the ring links. This particular link is called Ring Protection Link (RPL), and under normal conditions this ring link is blocked, i.e. not used for service traffic (as denoted by dotted line in Fig.l). One designated Ethernet ring node, the RPL Owner Node, is responsible for blocking traffic at one end of the RPL. Under an Ethernet ring failure condition, the RPL Owner Node is responsible for unblocking its end of the RPL (unless the RPL has failed) allowing the RPL to be used for traffic.

As illustrated on the left side of Fig.1 , each node over the ring runs link continuity detection mechanism to detect the link failure or the adjacent node failure. If the link between R6 and R5 fails, R6 and R5 send out the failure notification along the ring, as illustrated on the right side of Fig.l . Upon receipt of failure notification, R4, the protection link owner, unblocks its port for the protection link. At this point, all the nodes over the ring may flush their local Filtering Database (FDB), e.g., delete all the entries in MAC forwarding table.

Due to the flushing, the destination MAC address of a received packet will be unknown to the node, and the packet will be "flooded" through all the ports except the incoming port, while the nodes over the ring learn the source MAC address of the received packets. After the packet flooding and MAC learning, the Ethernet ring becomes stable again.

However, the existing solution with the packet flooding as discussed above might cause serious packet congestion and loss, leading to a delay or drop of the data traffic that is destined for any of the over-loaded downlink ports. Moreover, the convergence time, i.e. the time for the Ethernet ring to regain stability after any topology change due to an addition or a removal of a switch, a link failure, a configuration change of the ring, or a hardware replacement, is still too long to meet the requirement in practice, which is usually 50ms.

Though some researchers have made progress in extending the standard of Ethernet ring protection to distribute the MAC address over the ring on the purpose to expedite the MAC learning procedure. However, not only is the extension far from the wide acceptance by the academic and the industry, it will also increase the burden of the control plane, since this kind of solutions are often based on a request/reply model.

Hence, there is still need for an efficient solution regarding protection switching in Ethernet ring, especially to shorten the flooding period, accelerate the ring convergence, and be easily accepted by the existing systems.

Summary of the Invention

The object of the present invention is to address at least one of the problems outlined above, and particularly to provide an improved solution for protection switching in Ethernet ring that can be conveniently incorporated into existing systems or devices without increasing complexity in either software or hardware.

In one aspect of the invention, a method in an Ethernet ring node for protection switching of an Ethernet ring is provided, said method comprising: generating one or more fake Ethernet packets in response to a ring topology change; and sending out said one or more fake Ethernet packets to its neighbor ring nodes over the Ethernet ring, wherein each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to said ring node.

In yet another aspect of the present invention, a method in an Ethernet ring node for protection switching of an Ethernet ring is provided, said method comprising: receiving one or more fake Ethernet packets generated by a second ring node in said Ethernet ring where each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to the second ring node; learning one or more source MAC addresses from the received one or more fake Ethernet packets; and forwarding the received one or more fake Ethernet packets over the Ethernet ring.

In still another aspect of the present invention, a node device in an Ethernet ring topology is provided, said device comprising: a generator unit, configured to generate one or more fake Ethernet packets in response to a ring topology change; and a transmission unit, configured to send out said one or more fake Ethernet packets to its neighbor ring nodes over the Ethernet ring, wherein each one of the fake Ethernet packets contains one source MAC addresses learnt from one client subnet attached to said ring node.

In still another aspect of the present invention, a node device in an Ethernet ring is provided, said device comprising: a receiving unit, configured to receive one or more fake Ethernet packets generated by other ring nodes in said Ethernet ring where each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to the other ring nodes; a learning unit, configured to learn one or more source MAC addresses from the received one or more fake Ethernet packets; and a forwarding unit, configured to forward the received one or more fake Ethernet packets over the Ethernet ring.

Embodiments of the present invention provide solutions for protection switching in Ethernet ring based on the proactive transmission of fake Ethernet packets, so as to facilitate the MAC learning process in each ring node after any ring topology change and thus accelerate the ring convergence. With the transmission of fake Ethernet packets, unknown packet flooding would be considerably suppressed. Complying with the current L2 forwarding functionalities and the standards for Ethernet ring protection, such as ERP and RRPP, the introduction of fake Ethernet packet ensures that the present invention may be easily compatible with existing devices, such as the existing commodity L2 switches, and no signaling or forwarding enhancement are needed. Despite a small amount of traffic due to the transmission of these additional Ethernet packets, it is virtually impossible to cause congestion.

Brief Description of the Drawings

The foregoing and other objects, features, and advantages of the invention will be apparent from the following more particular description of preferred embodiments as illustrated in the accompanying drawings, in which:

Fig.l illustrates a typical Ethernet ring.

Fig.2 is a flowchart illustrating the process in a node device for protection switching according to one aspect of the present invention.

Fig.3 illustrates an exemplary structure of the fake Ethernet packets according to one embodiment of the present invention.

Fig.4 is a flowchart illustrating the process in a node device for protection switching according to another aspect of the present invention.

Fig.5 is a first embodiment illustrating the fake Ethernet packets distribution according to the present invention.

Fig.6 is a second embodiment illustrating the fake Ethernet packets distribution according to the present invention.

Fig.7 is a third embodiment illustrating the fake Ethernet packets distribution according to the present invention.

Fig.8 illustrates the usage of existing commodity forwarding chips in transmitting the fake Ethernet packets according to the present invention.

Fig.9 is a block diagram illustrating a node device for protection switching according to one aspect of the present invention.

Fig.10 is a block diagram illustrating a node device for protection switching according to another aspect of the present invention.

Detailed Description

While the invention covers various modifications and alternative constructions, embodiments of the invention are shown in the drawings and will hereinafter be described in detail. However it should be understood that the specific description and drawings are not intended to limit the invention to the specific forms disclosed. On the contrary, it is intended that the scope of the claimed invention includes all modifications and alternative constructions thereof falling within the scope of the invention as expressed in the appended claims.

Unless defined in the context of the present description, otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs.

The present invention may be applicable in an Ethernet ring which are used as an access ring or aggregation ring in an Ethernet network, where each ring node is configured to provide services to a large number of network hosts where most data traffic originates and terminates. Specifically, each ring node may be arranged to be connected with one or more segments of the Ethernet network, often referred to as subnets, which may consist of one or more network host, i.e, network communication devices like general-purpose computers. In this case, an Ethernet ring node may be linked to its adjacent ring node through ring ports, while linked to the subnets through other interfacing ports, usually termed as drop ports. Serving as a bridge between the subnets of the Ethernet network, the ring nodes are capable of forwarding a received data packet to the required port or ports.

Usually in an Ethernet network, each host device may be assigned a Media Access Control (MAC) address as a unique identifier for communications on the physical network segment. Typically, upon receiving an Ethernet packet through a port, a ring node device, such as a switch, examines the source address in the header of the packet and records on which port it was received, learning the source MAC addresses of the host device connected via each port. The associations between source MAC addresses and the interfacing ports of the node are stored in the filtering database (FDB) as a MAC forwarding table within the ring node.

Any change of the Ethernet ring topology due to an addition or a removal of a switch, a link failure, a configuration change, or a hardware replacement may cause the FDB flushing. As mentioned above, the FDB flushing method adopted in the current Ethernet ring protection mechanism has the drawback of introducing a large amount of transient traffic overshoot caused by flooded Ethernet frames. On the contrary, embodiments of the present invention provide much more efficient approaches to distribute the MAC addresses of the hosts located in the client subnets to nodes over the ring within a short period of time right after the ring topology change. With a fast populating of FDB by the proactive MAC address distribution, traffic overshooting due to the packet flood may be effectively eliminated.

Fig.2 is a flowchart illustrating the process in a node device for protection switching according to one aspect of the present invention. In response to a ring topology change, the node device, such as a switch may generate one or more fake Ethernet packets at step 101 , where each one of the fake Ethernet packets contains one source MAC address learnt from client subnets attached to this node device. The topology change in an Ethernet ring can be caused for example by an addition or a removal of a switch, a link failure, a configuration change of the ring, or a hardware replacement. As mentioned above, one node device may be connected with one or more client subnet, while each client subnet may consists of one or more host devices. Any change in the Ethernet ring topology may trigger a MAC learning process where each node device learns to associate MAC addresses of these host devices to a specific port that is functioning after the topology change. According to embodiments of the present invention, the MAC address of every one host device located in the client subnets of one node device will be contained in a respective fake Ethernet packet so as to be distributed to other node devices in the ring, that is one fake Ethernet packet for one source MAC address. Thus, the number of fake packets generated by one node device is always identical to the number of source MAC addresses learnt from the client subsets connected to that node device.

To accelerate the convergence, a node over the ring can distribute the source MAC addresses learnt from its client subnets to the other nodes via those fake Ethernet packet. As illustrated in Fig. l , the node device may send out the fake Ethernet packets as-obtained to its neighbor ring nodes over the Ethernet ring at step 102. Upon receiving the fake Ethernet packet, those neighbor nodes may learn the source MAC address and forward the fake packet over the ring, which will be described in detail below. Every functioning node devices in the ring may generate their own fake Ethernet packets and sending them out over the ring.

Fig.3 illustrates an exemplary structure of the fake Ethernet packets according to one embodiment of the present invention. To avoid the extension of the existing standard for Ethernet ring protection, the fake Ethernet packet may be generated as an Ethernet multicast packet, having a structure identical to a common Ethernet multicast packet as usually generated at a host device for data transmission. The only difference is that such a fake packet as described is generated by the node device instead of the client host device , that is why it is called "fake". With no additional packet format created, other nodes can learn the source MAC address information there-from using traditional function,

As illustrated in Fig.3, the fake Ethernet packet may have a source address field, a destination address field, VLAN ID field and payload. In one embodiment of the present invention, the source MAC address is provided with one of the source MAC address learnt from the client subnets, while the destination MAC address field within the destination address is assigned a specific reserved Ethernet multicast address. The payload may be meaningless, since no particular information is intended to be contained in this field.

Fig.9 is a block diagram illustrating a node device for protection switching according to one aspect of the present invention. In the embodiment as shown in Fig.9, node device 300 may comprise a generator unit 301 and a transmission unit 302. The generator unit 301 may be configured to generate one or more fake Ethernet packets in response to a ring topology change. The transmission unit 302 may be configured to send out said one or more fake Ethernet packets to neighbor ring node devices o node device 300 over the Ethernet ring. As discussed above, each one of the fake Ethernet packets may contain one source MAC addresses learnt from one client subnet attached to node device 300.

Fig.4 is a flowchart illustrating the process in a node device for protection switching according to another aspect of the present invention, teaching how a node device handles the fake Ethernet packets generated by other node devices in the ring as described above. According to embodiments of the present invention, except for generating fake Ethernet packets and sending them out by its own, a ring node device may also receive one or more fake Ethernet packets generated by other nodes in the ring from any of its ring ports at step 201. As described above, each one of the fake Ethernet packets may contain one source MAC address learnt from client subnets attached to the node device where the fake packets originate.

Then at step 202, the node device may learn the source MAC addresses from the received fake Ethernet packets. In one embodiment, the fake packets are generated as a multicast packet with the same structure as that of a common Ethernet multicast packet, where the source MAC address of every client host device is contained in the source address field of a respective fake packet so that the MAC learning process may be performed in a conventional way via existing hardware and software resources. For a common Ethernet multicast packet, the source MAC address field is filled with the originator's source MAC address, and the destination MAC address field is filled with a multicast address.

After the MAC learning process is completed, those received fake Ethernet packets may be forwarded over the Ethernet ring at step 203. In one embodiment according to embodiments of the present invention, the node device may be configured to forward the received fake Ethernet packets to all of its ring ports other than the incoming ring ports of those packets, i.e., the ring ports from which the fake Ethernet packets are received. Specially, if the ring port for forwarding the fake Ethernet packets is adjacent to a fault point or a protection link over the Ethernet ring, the node device may be configured to forward the received fake packets a black hole, i.e. these fake packets may be discarded. Generally, a fault point in the Ethernet ring for example may include a fault link or a fault node.

In the embodiment where a fake packets is generated as a multicast packet with the same structure as that of a common Ethernet multicast packet, its destination MAC address field may be filled with a reserved Ethernet multicast address. In this case, for a node over the Ethernet ring, a multicast forwarding entry with said reserved multicast Ethernet address may be set in an Ethernet forwarding table i.e., in the filtering database. Such entry may usually be set upon transmission or receipt of a failure report, FDB flush event, or restore notification. Within the forwarding entry, ring ports of the ring node are added into one multicast group corresponding to the reserved Ethernet multicast address. For example, with reference to node Rl in Fig.5, its two ring ports leading to R6 and R2 may be added into a multicast group. For an interconnection node of two rings, for example Rl in Fig.7, three ring ports should be put into a multicast group. In light of the multicast forwarding entry, every node device will be clearly aware of where to forward the received fake Ethernet packets.

Distributing the fake Ethernet packets generated by each ring node in a multicast way may bring the advantage that bandwidth can be saved. For use in the Ethernet ring, a reserved Ethernet multicast address can avoid conflict and unexpected behavior on the ring nodes once the Ethernet multicast address is in use for other purposes. As known to those skilled in the art, quite a few Ethernet multicast addresses have been designated for particular usage, such as "01-00-OC-CC-CC-CC" in Cisco Discovery Protocol (CDP), "01-80-C2-00-00-08" in Spanning Tree Protocol (for provider bridges). As a reserved Ethernet multicast address that has not been specified, "01-80-C2-00-00-20" may be used in the implementation of the present invention.

Fig.10 is a block diagram illustrating a node device for protection switching according to another aspect of the present invention. In the embodiment as shown in Fig.10, node device 400 may comprise a receiving unit 401 , a learning unit 402, and a forwarding unit 403. The receiving unit 401 may be configured to receive one or more fake Ethernet packets generated by other ring nodes in the Ethernet ring. As discussed above, each one of the fake Ethernet packets may contain one source MAC address learnt from one client subnet attached to the other ring nodes. The learning unit 402 may be configured to learn one or more source MAC addresses from the received one or more fake Ethernet packets. The forwarding unit 403 may be configured to forward the received one or more fake Ethernet packets over the Ethernet ring.

In order to obtain a rapid FDB update in response to any topology change in the Ethernet ring, every node device according to embodiments of the present invention may be configured to execute the steps as illustrated in both Fig.2 and Fig.4. Also, every node device according to embodiments of the present invention may be configured to include the function modules as illustrated in both Fig.9 and Fig.10. However, it is easy for those skilled in the art to understand that the partition of function modules in Fig.9 and Fig.10 is shown only in a non-limiting way. Each node device in the Ethernet ring could be implemented in various ways to perform the steps or functions as discussed above.

In the event of a protection switching with the prior art, the packets will be flooded over the ring to all ring ports and drop ports due to the FDB flush, which usually causes packet congestion and loss. In the embodiments of the present invention, once the fake packets circulate over the ring, the flooding can be terminated immediately, since an updated FDB has been recreated during the fake packet distribution. In order to suppress flooding, the fake packets are suggested to be transmitted in advance of the customer traffic. Since the nodes over the ring need to send only one fake packet for one host located in the client subnet, there will not be many fake packets. The nodes over the ring can complete the fake packets generation, transmission and MAC learning in a very short time.

The transmission of fake Ethernet packets as described above may introduce a small amount of traffic. However, overhead caused thereby is within an acceptable range, which will not cause any congestion. Assuming that each fake packet is about 64B (512 bits) and the number of the fake packets is not big, obviously no big amount of traffic volume will be consumed.

In a typical ERP or RRPP deployment in access network, a ring usually consists of no more than 8 nodes and no more than 2000 hosts are attached to a single node on the ring. In such deployment, the number of the fake packets is 16K and the total size is about 8M bits. For a 10G Ethernet ring, 8M bits is about 1/1000 of the traffic over the ring in a second. So, the transmission of fake Ethernet packets will not introduce any congestion.

Fig.5 is a first embodiment illustrating the fake Ethernet packets distribution according to one embodiment of the present invention. Generally, when a ring topology change occurs, for example a link or node fails, the nodes adjacent to the failure or the fault point as illustrated in Fig.5, i.e. R6 and R5, send out the "Failure report" in the reverse direction to the failure according to a typical ERP procedure. Upon receipt of the Failure report, the other nodes over the ring release the MAC address learnt from the ring ports, while R4 unblocks the protection port. At this point, the fake Ethernet packets generated by R6 according to the embodiment of the present invention may be distributed over the ring as follows:

1. R6 sends to Rl the fake packets with the source MAC addresses learnt from its client Subnet 6A and 6B;

2. Rl learns the source MAC addresses and forwards the fake packets to R2;

3. R2 learns the source MAC addresses and forwards the fake packets to R3;

4. R3 learns the source MAC addresses and forwards the fake packets to R4;

5. R4 learns the source MAC addresses and forwards the fake packets to R5;

6. R5 learns the source MAC addresses and forwards the fake packets to a black hole (i.e. discard the fake packets).

Thus, the MAC addresses of the host devices located in Subnet 6A and 6B could be learnt by all the functioning nodes in the ring.

Fig.6 is a second embodiment illustrating the fake Ethernet packets distribution according to one embodiment of the present invention. The ring structure is the same as illustrated in Fig.5. The fake Ethernet packets generated by R2 in the same situation as R6 according to the embodiment of the present invention may be distributed over the ring as follows:

1. R2 sends to Rl and R3 the fake packets with the source MAC address learnt from its client Subnet 2;

2. Rl learns the source MAC addresses and forwards the fake packets to R6;

3. R6 learns the source MAC addresses and forwards the fake packets to a black hole (i.e. discard the fake packets);

4. R3 learns the source MAC addresses and forwards the fake packets to R4;

5. R4 learns the source MAC addresses and forwards the fake packets to R5;

Thus, the MAC addresses of the host devices located in Subnet 2 could be learnt by all the functioning nodes in the ring.

Fig.7 is a third embodiment illustrating the fake Ethernet packets distribution according to one embodiment of the present invention. A typical multiple interconnected Ethernet ring deployment composed of a primary ring and a sub ring is shown in Fig.7, where the present invention is also applicable. In the primary ring, a protection link lies between R4 and R5, while in the sub ring, a protection link lies between R7 and R8. Similarly, if the link between R6 and R5 fails, R6 and R5 may send out the failure report along the primary-ring. Upon receipt of failure report, R4, the protection link controller of the primary-ring, unblocks its protection port. The interconnection node between the primary ring and the sub-ring, Rl and R3, propagate the failure report in the sub-ring. Thus all the switches will flush their local FDB. At this point, the fake Ethernet packets generated by R6 according to the embodiment of the present invention may be distributed over the ring as follows: 1. 6 sends to Rl the fake packets with the source MAC addresses learnt from its client Subnet 6 A and 6B;

2. Rl learns the source MAC addresses and forwards the fake packets to R7 and R2;

3. R7 learns the source MAC addresses and forwards the fake packets to a black hole (i.e. discard the fake packets);

4. R2 learns the source MAC addresses and forwards the fake packets to R3;

5. R3 learns the source MAC addresses and forwards the fake packets to R4 and R9;

6. R9 learns the source MAC addresses and forwards the fake packets to R8;

7. R8 learns the source MAC addresses and forwards the fake packets to a black hole (i.e. discard the fake packets);

8. R4 learns the source MAC addresses and forwards the fake packets to R5;

9. R5 learns the source MAC addressed and forwards the fake packets to a black hole (i.e. discard the fake packets).

Thus, the MAC addresses of the host devices located in Subnet 6A and 6B could be learnt by all the functioning nodes in both primary ring and sub ring.

Fig.8 illustrates the usage of existing commodity forwarding chips in transmitting the fake Ethernet packets according to embodiments of the present invention, As explained above, the fake Ethernet packet is preferably generated as an Ethernet multicast packet where a reserved Ethernet multicast address is provided in the destination MAC address field. In this situation, with a multicast forwarding entry with the specific reserved multicast Ethernet address set in the FDB, embodiments of the present invention can work on the existing commodity forwarding chips.

Fig.8(a) illustrates how FDB lookup engine works with a normal Ethernet packet. Firstly, a received Ethernet packet is parsed so as to identify it source MAC address and destination MAC field. The destination MAC address will be fed into FDB lookup engine to find an appropriate outsegment port, while the source MAC address will be fed into the FDB lookup engine to check whether or not the node device knows the existence of the packet originator. If the result of source MAC (SMAC) address lookup is missed, the SMAC address learning module will insert the SMAC into FDB; in another aspect, the packet will be forwarded to the corresponding output port according to the destination MAC address (DMAC) as recorded in the FDB.

Fig.8(b) shows how a fake packet goes through the forwarding chip: the SMAC address learning module will serve as a learning unit (402) configured to learn the source MAC address from the received fake Ethernet packet. As mentioned above with respect to Fig.8(a), the host addresses in subnets into FDB if there is no such entry therein after flushing, while the fake packets will be forwarded to the corresponding ring ports according to the forwarding entry associated with the reserved Ethernet multicast address. It is very clear that the Forwarding Chip could treat the fake packet as a normal Ethernet packet and handles as usual. Therefore, no enhancement on forwarding chip is needed in this situation.

Thus, the invention according to the described embodiments provide more efficient protection switching in an Ethernet ring when a ring topology change occurs, including both single ring and multiple interconnected ring deployment, thereby avoiding the packet congestion and loss caused by the packet flooding and speeding the ring convergence with almost no requirements for modification of the existing systems or devices.

It should be noted that the aforesaid embodiments are illustrative of this invention instead of restricting it, substitute embodiments may be designed by those skilled in the art without departing from the scope of the claims below. The wordings such as "include", "including", "comprise" and "comprising" do not exclude elements or steps which are present but not listed in the description and the claims. It also shall be noted that as used herein and in the appended claims, the singular forms "a", "an", and "the" include plural referents unless the context clearly dictates otherwise. This invention can be achieved by means of hardware including several different elements or by means of a suitably programmed computer. In the unit claims that list several means, several ones among these means can be specifically embodied in the same hardware item. The use of such words as first, second, third does not represent any order, which can be simply explained as names.

Claims

1 , A method in an Ethernet ring node for protection switching of an Ethernet ring, said method comprising:

generating (101) one or more fake Ethernet packets in response to a ring topology change; and

sending out (102) said one or more fake Ethernet packets to its neighbor ring nodes over the Ethernet ring, wherein

each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to said ring node.

2. The method according to claim 1, wherein said fake Ethernet packet is generated as an Ethernet multicast packet, and said source MAC address is contained in the source address field of said fake Ethernet packet.

3. The method according to claim 2, wherein said fake Ethernet packet has a destination MAC address field, and said destination MAC address field is filled with a reserved Ethernet multicast address.

4. A method in an Ethernet ring node for protection switching of an Ethernet ring, said method comprising:

receiving (201) one or more fake Ethernet packets generated by a second ring node in said Ethernet ring where each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to the second ring node; learning (202) one or more source MAC address from the received one or more fake Ethernet packets; and

forwarding (203) the received one or more fake Ethernet packets over the

Ethernet ring.

5. The method according to claim 4, wherein said fake Ethernet packet is generated as an Ethernet multicast packet, and said source MAC address is contained in the source address field of said fake Ethernet packet.

6. The method according to claim 5, wherein said fake Ethernet packet has a destination MAC address field, and said destination MAC address field is filled with a reserved Ethernet multicast address.

7. The method according to claim 6, wherein a multicast forwarding entry with said reserved multicast Ethernet address is set in an Ethernet forwarding table, where ring ports of said ring node are added into one multicast group corresponding to the reserved Ethernet multicast address; and

the fake Ethernet packets are forwarded according to said multicast forwarding entry.

8. The method according to claim 4, wherein the received fake Ethernet packets are forwarded to all ring ports of said ring node other than its ring port from which the fake Ethernet packets are received;

if the ring port for forwarding the fake Ethernet packets is adjacent to a fault point or a protection link over the Ethernet ring, the fake Ethernet packets are forwarded to a black hole.

9. A node device in an Ethernet ring topology, said device comprising:

a generator unit (301), configured to generate one or more fake Ethernet packets in response to a ring topology change; and

a transmission unit (302), configured to send out said one or more fake Ethernet packets to its neighbor ring nodes over the Ethernet ring, wherein

each one of the fake Ethernet packets contains one source MAC addresses learnt from one client subnet attached to said ring node.

10. The device according to claim 9, wherein said fake Ethernet packet is

generated as an Ethernet multicast packet, and said source MAC address is contained in the source address field of said fake Ethernet packet.

1 1. The device according to claim 10, wherein said fake Ethernet packet has a destination MAC address field, and said destination MAC address field is filled with a reserved Ethernet multicast address.

12. A node device in an Ethernet ring, said device comprising:

a receiving unit (401), configured to receive one or more fake Ethernet packets generated by other ring nodes in said Ethernet ring where each one of the fake Ethernet packets contains one source MAC address learnt from one client subnet attached to the other ring nodes;

a learning unit (402), configured to learn one or more source MAC addresses from the received one or more fake Ethernet packets; and a forwarding unit (403), configured to forward the received one or more fake Ethernet packets over the Ethernet ring.

13. The device according to claim 12, wherein said fake Ethernet packet is generated as an Ethernet multicast packet, and the source MAC address is contained in the source address field of said fake Ethernet packet.

14. The device according to claim 13, wherein said fake Ethernet packet contains a destination MAC address field, and said destination MAC address is filled with a reserved Ethernet multicast address.

15. The device according to claim 1 , further comprising:

a processing unit, configured to set a multicast forwarding entry with said reserved Ethernet multicast address in an Ethernet forwarding table, where ring ports of said ring node are added into one multicast group corresponding to the reserved Ethernet multicast address; and

the forwarding unit is configured to forward the fake Ethernet packets according to said multicast forwarding entry.

16. The device according to claim 12, wherein the forwarding unit is configured to forward the received fake Ethernet packets to all ring ports of said ring node other than its ring port from which the fake Ethernet packets are received ; and

the forwarding unit is configured to forward the fake Ethernet packets to a black hole if the ring port for forwarding the fake Ethernet packets is adjacent to a fault point or a protection link over the Ethernet ring.