Patent Application
20120257539
This application claims priority of Israel Patent Application No. IL-212191, filed Apr. 7, 2011, the disclosure of which is incorporated by reference herein in its entirety.
The present invention relates to a technology of relearning MAC (Media Access Control) addresses in modern communication networks, more specifically to a rationalized MAC withdrawal technique in Ethernet networks, Carrier Ethernet networks, and especially in MPLS (Multi-Protocol Label Switching) networks.
Relearning MAC addresses is a well-known procedure in modern communication networks, and usually it takes place when the network topology changes. In such situations, data packets which earlier arrived to some switch/nodes from one source (having MAC address 1) via a specific port of the switch, suddenly start arriving via another port not yet known/familiar to that switch. To relearn the MAC address 1 in association with the new port, the previously learned information (about association of the MAC address 1 with the previous specific port) should be deleted, in other words “flushed” from that specific port (i.e., from the forwarding database (FDB) of the node with respect to that specific port). The flush operation actually means a) deleting the previous information about the MAC address 1 at that port, b) flooding packets addressed to the MAC address 1 of interest via all ports of the switch; c) upon receiving a first response packet from the source having MAC address 1, registering this MAC address 1 in association with the new port via which that response packet has arrived at the switch.
In case of a failure/configuration change either in a node A having MAC address 1 (MAC 1), or in a network section associated with and reachable through that node A (e.g., for a specific service/traffic flow), another node B (e.g., a Core node) not belonging to the mentioned network section but being in communication with the discussed node A, should erase (flush) all MAC addresses of A and the associated network section from its (node's B) FDB.
It is usually initiated by sending a specific message “about changes” to the node B from node A. The the message may list ports to be “flushed”. Alternatively, (if not listed) node B flushes (deletes) MAC address of node A which means any network section reachable through node A becomes “unfamiliar” to node B.
However, the mentioned network section used by the specific traffic flow and appended to a port of node A is usually not the only network section/traffic flow served by node A. Other physical ports, or even other logical ports of node A may serve other traffic flows/network sections and they all will be “flushed’ (will become unknown) together with flushing the node's A MAC from FDB of node B. It will then cause unjustified flooding in the whole network. The slow flush procedure leads to losses of traffic immediately after the flushing and, consequently, causes service disruption.
Simply speaking, there is the following situation. In real networks, not only a single discussed MAC address (e.g., MAC1), but many other MAC addresses can be associated with the port being flushed. Even if MAC 1 moves to another port, other MAC addresses may need to remain registered at the discussed port.
Nowadays, a typical Carrier Ethernet network comprises multi-home regions interconnected by a backbone core network. One of possible implementations of such a network may comprise a number of access networks, so-called Access Rings further aggregated by a Metro/Core MPLS network. The Access Rings may be understood either as physical rings or as logical rings formed in an access network, for example for a specific traffic service.
In the case of any topology change in a specific Access Ring, a Topology Change Notification (TCN) should be delivered to all relevant Core nodes which are part of the services affected by the topology change. A standard mechanism of the approach comprises sending a MAC Withdraw message with a list of MACs (MAC addresses) to be withdrawn (from FDBs of the core nodes). The Core Network Nodes are required to remove all MAC addresses received in the MAC Withdrawal notification.
Such a MAC withdrawal operation is usually based on a so-called Control Path, implemented by software, and requires a relatively long time to be completed. If the message must comprise the full list of affected MAC addresses registered on the affected port, it will not be scalable for large networks. For example, a 10K MACs list just does not fit a regular CCN PDU (Change Configuration Notification Protocol Data Unit). Therefore such a way is slow (may take minutes) and complicated (requires keeping an updated list of MACs in a Central Processing Unit CPU). As a result, a traffic hit may occur during the MAC Withdrawal processing time. An alternative way to withdraw MAC addresses may include sending a “wildcard” MAC withdraw notification which requires removing all MACs registered at the Core Edge (Core node). This usually results in flushing of all MACs, including those received from other access rings/regions at the same Code Node.
The following prior art documents disclose resolving problems of the MAC flush/relearn operations:
CN101330424A discloses a method for handling a service failure of a virtual private network and relates to the technical field of network communications. The method comprises the following steps: a second provider edge device (PE) sends a Flush message to a switch when a failure occurs between a first client edge (CE) device and a second CE device, wherein the second PE device turns into a forwarding state; eliminating a medium access control (MAC) address list of the switch according to the Flush message; eliminating a MAC address list of a third PE device. The invention further discloses a virtual private network (VPN) failure handling system, which comprises the switch, a first PE device, the second PE device and the third PE device. The method solves the problem that a CE dual-homing network switch interface of a virtual private LAN service (VPLS) network cannot update in time, so as to improve the reliability of the VPLS network. The CN101330424A actually describes a standard MAC withdrawal method/message mentioned above in the background description, and does not propose a solution for MPLS networks.
U.S. Pat. No. 6,330,229B describes an approach for management of forwarding databases in the case of link failures on bridges according to the all improved spanning tree, which limits the propagation of notifications of topology change to only those parts of the network which are affected by the link failures, and triggers partial flushing as opposed to complete forwarding database flushing of learned MAC addresses to relearn the sets of addresses associated with ports affected by the change in topology. When a bridge moves its root port to a new port, the bridge can move the addresses learned through the original root port to the new root port without any relearning. The sets of addresses associated with the designated ports on upstream bridges from the old root port, are subject to flushing. Also when the bridge attaches to the new branch, it triggers a message to the root instructing all bridges in the new path to the root to flush addresses learned on their root ports. Actually, the solution is for Provided Bridge (PB) networks, and suggests transferring lists of MACs from one port to another port.
Neither of the published or practically used prior art solutions are known tp propose an effective way of rationalizing the MAC withdrawal procedure, and especially in MPLS networks.
It is an object of the invention to create a modified mechanism for intelligent MAC learning with a rationalized MAC withdrawal (flush) procedure.
Two goals of the rationalized MAC withdrawal in a network are formulated comprising a number of component network domains:
The two goals actually form one version/embodiment of the invention: a rationalized MAC withdrawal method in a communication network comprising two or more component network domains with network nodes, wherein an intermediate node interconnects a remote node with two or more said component network domains accommodating MAC addresses (MACs). One aspect of the method allows and comprises:
To achieve the goals and to perform the method of rationalized MAC addresses (MACs) withdrawal in the mentioned communication network comprising two or more (component) network domains of network nodes, the following steps preferably be provided:
A more specified method may explicitly comprise learning MACs at the network nodes in association with the network domains from which said MACs respectively originated, and, in case of a topology change and upon receiving the suitable notification at the network node(s), consequently comprises flushing at the node(s) only MAC addresses related to the changed network domain.
The “remote node” (which is sometimes called a core node in this application) should be understood as a node which is not directly connected (does not belong) to the access ring; the core node and the access rings/domains usually have intermediate (access) nodes there-between.
MACs in the FDB of a network node (and in a specific case, in the remote/Core node) are considered to be associated with a particular access ring/domain if they were received (i.e., learned) from that ring/domain.
It should be noted, however, that the network node which constitutes an intermediate node for one constellation of network domains, may be a core node for another constellation (group) of network domains of one and the same combined network.
The technology is proposed preferably for MPLS networks, though it can be used also in Ethernet networks and in any kind of segmented networks where address learning is used for forwarding data packets/frames, and various control protocols are used to control network topology to eliminate loops. Preferably, the core network is an MPLS network.
The access networks (rings) may be understood either as physical rings such as fiber rings, or as logical rings formed in any access domain (for example in a mesh-like network) for a specific traffic service. Such rings typically utilize redundancy nodes (usually, a dual homing configuration).
The dual homing nodes are usually intended for providing protection to traffic services which are to be passed to a remote/core network (where a destination core node receives the traffic). Usually, the traffic is bidirectional, i.e. the core node may become a source node and send data frames to access networks. The access rings are usually open, i.e. have a physical or a logical gap to prevent forming loops (which is provided either manually or by loop-preventing algorithms such as x-STP, ERP, etc.)
The method allows rationalizing the MAC withdrawal procedure (flushing of MAC addresses) already at the level of component access networks connected to two or more access nodes.
In a communication network comprising at least two access nodes connected to access networks (access Rings), wherein at least one of the access nodes is connected to two access networks, the method of flushing MAC addresses in a specific access node comprises:
The notification may be understood, for example, as a MAC withdrawal CCN (configuration change notification) and the notification should contain the ID of the topologically changed domain (e.g., RID—ID of the reconfigured/failed ring). For access/intermediate nodes such a notification already allows rationalizing the flushing procedure, since RID is associated with a specific port, and MACs registered to such a port will be withdrawn. The remote notification may comprise a list of IDs (RIDs) in case topology changes occurred in a number of network domains associated with the specific access node.
In a more advanced version of the method, the network comprises a core node connected to said access nodes; the method also comprises a procedure of rationalized flushing of MACs in the core node, by performing the following operations:
The necessary indications (of the intermediate node, of the access ring) can be performed either by using tags (labels) of MPLS packet, or by using various fields of an Ethernet packet. The remote notification is actually a new type of a topology change notification, which has been proposed by the Inventors. It should be mentioned that such a remote notification to a remote/core node did not exist before.
Therefore, in the communication network at least one intermediate/access node interconnects a remote/core node with two or more of component network domains (access networks). The method further comprises sending one of said notifications of topology change from an intermediate node to the core node, and such a specific notification will be a remote notification informing the core node about topology change in a specific network domain associated with said intermediate node.
The following preliminary steps may be performed for the method:
According to another aspect of the invention, the proposed method may be considered as an independent technique for rationalizing MAC withdrawal at a core node. At least at a core node (but preferably, at any node of the network since it may be a core node to other network nodes), the method suggests:
According to another aspect of the invention there is also proposed a network dividable into a number of network domains comprising a core network and two or more access networks with a group of intermediate (access) network nodes being interconnected with a core node located in the core network, the network being adapted to implement the above-described optimized method of flushing MAC addresses.
There is also proposed a software product comprising computer implementable instructions and/or data for carrying out the method as described above, the software product being stored on an appropriate non-transitory computer readable storage medium so that the software is capable of enabling operations of said method when used in a computer system.
The computer system may be understood as a distributed system comprising control& processing units (CPUs) of the intermediate nodes and the core node. The computer system may be a node's control block CPU, such as in the form of a network element management system EMS, or the network management system NMS, or a combination thereof.
It should be reminded, however, that a network node being an intermediate node for one constellation of network domains, may be a core node for another constellation (group) of network domains. Therefore, the software product may be accommodated in its complete version in one node, and may be distributed between different nodes as well.
The invention will be further described and illustrated in detail as the description proceeds.
The invention will be further described and illustrated with the aid of the following non-limiting drawings in which:
The problem known in the prior art is as follows. In case of failure in one of the access rings (e.g. Ring 1, see a cut shown by a “cross” which will cause protection switching in the Ring 1), a topology change notification will be sent to PE-1 and PE-2 (shown by circular arrows), and both PE-1 and PE-2 will flush MACs per bridge/node (see symbolic explosions on the nodes PE-1, PE-2), i.e. for all MACs registered in these nodes. Traffic on the access network/rings R2 and R3 will also be affected since MAC addresses of R2, R3 learned in the PE-1, PE-2 will be withdrawn due to the flush of R1, R2.
The network nodes should be adapted to produce modified CCNs in case of a fault, carrying indication of the relevant RID where the fault occurred.
CCN* is a CCN concerning a fault in access ring R1.
CCN** are CCNs sent from PE-1 and PE-2 to a remote (core) node PE4, carrying indication of the fault in access ring R1 by including it in a list of failed access rings.
As a result:
P1 and P2 will flush MAC addresses in response to the CCN*, but traffic from Rings 2 and 3 should be unaffected by PE-1 and PE-2 flushes. It can be done if PE-1 and PE-2 flush only MACs on the same ring R1, and that can be implemented by two separate flushes per [VSI (service), port]. The ports to be flushed can be found by Ring ID (RID1), since it is assigned to the relevant ports of PE-1 and PE-2.
VSI is a service. All services from the same port will be flushed together if they are triggered by the same CCN/alarm. In the general case they are flushed separately. A number of services (rings) may pass via one port, and each service ring, if necessary, will be “flushed” separately.
Further, according to the CCN**, PE-4 should flash only MACs previously learned as originating from Ring-1. To do that:
To propagate information about access rings in the network, the Inventors propose that data frames in the network (at least the data frames outgoing from access nodes to a core node) carry indication of the access ring from which a specific frame originates.
The ring ID can be transferred in a number of ways:
There is special field which may be added in a proprietary implementation—a new field well known in the proprietary frame layout—for example, it is the 1st byte immediately after the MPLS stack.
Learning of MAC addresses at the core node may be performed in a number of sub-steps:
The first sub-step requires providing the core node with the ring/network domain ID of a packet (see
The next sub-step of learning MAC addresses by the core node requires “extracting” the ring IDs from the received packets arrived from one or another intermediate nodes, and building a table of virtual ports (an example is in
Remote (core) nodes in other remote Domains/Regions perform learning of MAC addresses according to a virtual interface, where each virtual interface is a combination of the access PE and the Network ID of the Region originating the received MAC.
According to
PE-4 learns MACs coming from PE-2 per following virtual interfaces: {PE-2, Access-ring-1}, {PE-2, Access-ring-2} and {PE-2, Access-ring-3}.
As mentioned in the Summary of the invention, responsible access nodes notify remote peers (such as PE-4) on a topology change in the relevant domain. For example, PE-1 and PE-2 will notify the PE-4 about the topology change in the Access Ring-1.
The step of notifying the core node about failures/changes in a specific access network (ring) may comprise the following possible sub-steps:
The step of MAC withdrawal (flushing) which does not affect non-changed network domains may comprise the following sub-steps performed at the core node (such as PE4):
Since, most probably, PE-2 also sends CCN indicating “Ring-ID 1”, MACs registered to Virtual port 3 will also be flushed in PE-4. As a result, the core node flushes only MACs known to the core node from the changed Ring having ID 1, while MACs in other network domains (rings) are not affected.
Flushing MACs per virtual interface can be further rationalized and shortened if the process is performed according to the Applicant's earlier and yet non-published patent application IL 205725 which is incorporated herein by reference.
The invention has been described with reference to the included examples and drawings, but may be implemented in a number of additional versions and embodiments which should be considered part of the invention whenever covered by the claims which follow.
| Number | Date | Country | Kind |
|---|---|---|---|
| 212191 | Apr 2011 | IL | national |
