Patent Application
20090274155
The invention relates to a technique for interconnecting communication networks, more particularly for providing a traffic protecting though loop free interconnection between layer 2 Ethernet and/or VPLS-packet networks.
An Ethernet network is composed of Ethernet switches connecting local area network (LAN) or IEEE 802.1Q virtual LAN (VLAN) segments containing end stations. A switch forwards packets between its interfaces (ports) based on media access control (MAC) destination address contained in each packet. An incoming packet may be forwarded to one or more outgoing ports, where the latter case is referred to as multicasting or broadcasting.
The CE-PE connection can carry Ethernet or Ethernet-VLAN packets. The provider may map the customer traffic into Provider Service VLANs (SVLANs) using VLAN stacking techniques (so called Q-in-Q encapsulation) in order to partition customer's traffic from the others.
A newly emerging technology has become known in the prior art, called virtual private LAN service (VPLS). A VPLS network emulates the functionality of a LAN, making it possible to interconnect multiple access networks over a VPLS network while all these access networks together behave as one single LAN or virtual LAN (VLAN). With VPLS, all these access networks would be assigned the same virtual private network (VPN) identification, this is analogous to assigning them the same SVLAN in an Ethernet-based provider network. With VPLS, the Ethernet packets arriving from the access network are appended with multi-protocol label switching (MPLS) headers, based on which they are forwarded across the provider network towards the remote LAN segments. This use of MPLS forwarding within the VPLS provider network allows to build networks that excel in performance, quality of service (QoS) for service differentiation, high resiliency (particularly fast rerouting, FRR), and scalability.
For convenience, we will refer to both SVLANs and VPLS VPNs used within the provider network as VPNs (Virtual Private Networks). VPLS architecture implements full-mesh connectivity between the PE nodes that connect the customer access networks, this allows each access network to communicate with any other access network belonging to the same VPN. Each PE-PE path carrying VPN traffic is called pseudo-wire (PW).
As an alternative to using Ethernet-VLAN on a CE-PE connection to classify customer traffic to specific VPN, a CE-PE connection (say, 20) can be a so-called spoke Pseudowire (spoke PW). With this method, known as hierarchical VPLS (H-VPLS), Ethernet packets already arrive encapsulated with MPLS headers (a.k.a., Martini encapsulation) on the CE-PE connection to the provider network. H-VPLS can be preferred over Ethernet-VLAN on the CE-PE connection, because it provides the aforementioned MPLS advantages also on the CE-PE connection and not only within the provider network.
A key aspect in Ethernet networks is avoiding layer 2 loops. A layer 2 loop occurs when multiple data routes exist between two end stations connected to an Ethernet network. A multicast or broadcast traffic introduced into Ethernet network with a layer 2 loop, will indefinitely keep circulating in the network, and might steadily consume more and more resources until the network overloads. Assuring loop-free topology is therefore essential to proper operation of Ethernet networks.
An important feature in packet-based applications is effective redundancy. The financial costs associated with unexpected downtime is leading service providers to build fault-tolerant networks. One option for achieving fault tolerant connectivity comes in the form of so-called dual homing or dual homing configurations. Dual homing adds reliability by allowing a device or a network to be connected to another device or network via two connections, such that when one connection fails the other one serves for carrying the traffic. The general case of dual homing is referred to as multi homing, with which redundancy is achieved via multiple rather than only two connections. This application mainly deals with dual homing for the sake of clarity, but it can be extended straightforwardly to support multi homing. Therefore, the term dual homing should be understood as “at least dual homing”, i.e. as a network interconnection configuration providing two or more alternative traffic paths therebetween.
A major concern in dual homing is avoiding the unbroken layer 2 loop that is created by the dual (or multi) homed connections, i.e., connections having two or more communication lines between the two networks. Breaking this loop can be done in various ways, that can be classified to two approaches:
A notable advantage of xSTP is that it can break a loop for any arbitrary Ethernet topology. A drawback of this method is the need to maintain xSTP signaling interaction between the switches. This is especially complicated when the dual homing connectivity is created between two networks running under different administrations, due to the xSTP provisioning and maintenance burden it inflicts upon the parties involved.
This prior art, described in http://www.alcatel.com/doctypes/opgapplicationbrochure/pdf/Resilient_HVPLS_an.pdf (hereby referred to as “Alcatel's”), requires that xSTP would run among CEs and PEs (see our
The object of the present invention is providing a simple technique for connecting Ethernet and/or VPLS networks, that would be capable of preventing traffic loops at layer 2, combine advantages of the above-mentioned two prior art approaches, while avoiding their drawbacks.
The Inventor has found that the above object can be achieved by
According to a second aspect of the invention, there is provided a software product, comprising computer implementable software instructions and/or data, suitable to be installed in any of said peer elements, and capable of implementing the two last steps of the above-described method (in particular, by providing exchange of signaling, or Hello, messages between the peer nodes). There is also provided a suitable computer readable medium where the software product is stored.
According to a third aspect of the invention, there is also provided a peer element (such as a gateway node) operative to implement the steps of the above described method, whenever said peer element is activated as part of the dual-homing configuration.
Alternatively, the proposed peer element can be defined as a network element suitable for serving as a peer in the dual homing configuration and provided with the above-mentioned software product, pre-installed therein.
Coming back to the above-proposed method, it should firstly be noted that it enables drastically simplifying the problem of interconnecting Ethernet and/or VPLS networks. No xSTP is required neither in the first network (say, an access network) nor in the second network (say, a provider network) for correct operation of the dual homing, and that is in contrast with the prior art approach (A) which requires xSTP at one or both of the connecting networks.
The above method renders the configuration fast protected and simple simultaneously. Those skilled in the art understand the term “fast protected” as being capable of performing switchover to its protection traffic line during a time period, which is much shorter than that could be ensured by previously known techniques.
For example, such a prior technique is RSTP protocol activated in a relatively large network such as an access network having multiple nodes. According to the proposed method, the time of the dual homing switchover can be of about 0.1 sec, i.e., much less than 1-2 sec provided by using a standard RSTP technology.
On the other hand, though the proposed method is comparable by its switchover time with a method where a separate xSTP protocol is activated per dual homed connection (as described in Alcatel's), it is much simpler than the Alcatel's technique since the proposed method does not require applying xSTP protocol for each multi/dual-homing configuration in the provider's network.
In comparison with the US 2006/0047851 (Cisco's), the proposed invention avoids drawbacks of the Cisco's, by: (a) using rather simple signaling (such as Hello signaling) eliminating the need for xSTP (b) avoiding signaling interaction between the CE and PEs (c) exchanging the Hello signaling only between the two PEs (peers) to which the CE is dual homed.
Let us assume as a condition, that both the access network and the provider network are a-priory loop-free, i.e., in the frame of the present application we do not take care of removing traffic loops pre-existing in any of the networks before they are interconnected by the dual-homing configuration. The task of the invention is to prevent loops which may be introduced/caused by the dual-homing connection.
As has been mentioned, the first of the mentioned networks can be an access (customer's) network, and the second network—a provider network. However, it can be just vise versa, it can also be that the two mentioned networks have nothing in common with an access and provider's network. Each of the two networks can be a network utilizing raw Ethernet traffic, Ethernet VLAN traffic or encapsulated Ethernet traffic, Martini encapsulation inclusive. In particular, each of them can be an Ethernet network or a VPLS network.
The mentioned at least three elements of the dual-homing (or multi-homing) configuration are preferably edge nodes or gateways of the two connected networks. Preferably, for a case when one of the networks is an access (customer) network and the other is a provider network, each of the elements is either a Customer's Edge node (CE) or a Provider's Edge node (PE). Further, said at least two elements belonging to one and the same (second) network—let them be called peer elements—will be either PE-s belonging to a provider network, or CE-s belonging to a customer's (access) network.
Usually, the peer elements are gateway PEs. (Keeping in mind that the term gateway indicates that the node belongs to one network and has connection to another network.)
It is understood, that said two or more elements belonging to one and the same network (the peer elements) form the basis of the required protected interconnection (i.e., the basis of multiple alternative communication lines). Therefore, each of these two or more elements must be prepared (provisioned) to receive and forward traffic from the second network to the first network and vice versa.
Let, for example, a loop-free access network is “dual homed” to a provider network. Let the dual homing configuration comprises two PE-s belonging to the provider network, and a single CE belonging to the access network. The configuration comprises two CE-PE traffic lines, and only one of them is supposed to be active at a time. From the access network's point of view, the provider network emulates the functionality of a LAN. Traffic over an active CE-PE connection is raw Ethernet or Ethernet-VLAN (either customer VLAN or SVLAN) or encapsulated Ethernet such as H-VPLS spoke PW. In order for the dual homing to operate correctly, at both gateway PEs there is provisioned the VPN (Virtual Private Network) assigned for the customer traffic.
Further preferably, for organizing the bidirectional signaling, the method comprises provisioning a bidirectional virtual link (VL) between each pair of said two or more peer elements belonging to the second network, and ensuring exchange of signaling messages between said peer elements pairwise. Preferably, the VL is dedicated for the signaling traffic.
The VL may be implemented by a dedicated provider S-VLAN or PW, or even by a physical link, as long as it assures that the signaling messages for the dual homing connection are exchanged between these two PEs.
To increase the VL reliability and assure low message delivery delay, the VL—or the means that are used to carry the signaling traffic, e.g., MPLS tunnels—may be protected (e.g., with MPLS fast rerouting mechanism-FRR) against failure of an intermediate node or links along the VL, use the shortest path available between the two PEs, have high traffic priority and/or packet error detection/protection means.
Specifically, the method may comprise prioritizing the signaling traffic over other traffic transmitted via the VL (if such other traffic is at all conveyed via the VL).
For establishing and maintaining the bi-directional signaling, the peer elements preferably should exchange periodic signaling messages (referred hereby as “Hello” messages) over the VL. The Hello messages may be implemented with standard or modified standard means, e.g. Ethernet or MPLS or PW Operations Administration and Maintenance (OAM) messaging, such as those described in ITU-TY.1710 and Y.1711.
Yet further preferable, that the above messages serve to elect the peer element which should be a “designated forwarder” in the dual-homing configuration.
The Inventor proposes the following way of performing the step of establishing the bi-directional signaling and the step of making the decisions:
According to the proposed concept, only one of the peer elements (say, PEs) is elected to be the designated PE (D-PE) at a time. The peers “agree” which one of them is the elected D-PE, this is indicated in the Hello messages. Only the D-PE puts its traffic line (CE-PE connection) in the forwarding state, i.e. it does receive and transmit packets through the connection, while the non-designated PE (N-PE) blocks its CE-PE connection, i.e. it does not send nor receive any packet on the connection. The blocking can also be implemented by deactivating the physical link between the PE and CE, or by putting the residing spoke PWs in standby state. It should be emphasized that, in the present patent application, blocking of a traffic line means that the line does not send nor receive any traffic on its CE-PE connection, unlike xSTP protocols where blocking still allows receiving BPDU packets.
Specific solutions of how the hierarchical status of the particular peer element can be reflected in the Hello messages, and how the status of the suitable traffic line can be introduced in the Hello messages sent from the particular PE will be described below with reference to the attached drawings.
The hierarchical function of the peer (D-PE or N-PE) can be re-elected during the operation, based on the mentioned information, which can be obtained using the Hello messages.
Re-election of the Designated element (say, D-PE) and consequently, re-election of the forwarding traffic line can be performed, for example, according to the following possible version of the sub-step (b): upon missing at a non-elected peer element N-PE a predetermined number of Hello messages from the D-PE, or upon receiving a defect indication (DI) from the D-PE, the N-PE becomes a D-PE itself; the new D-PE puts its associated traffic line (CE-PE connection) into a forwarding state.
It should be noted, that decisions on status change of a peer element should be regulated by a logical mechanism (for example, by a logical state machine) where various events affecting such decisions are prioritized to prevent racing (say, electing two D-PEs) and mis-election (e.g., no D-PE elected) in the absence of failures or the presence of up to one traffic line failure and/or up to one VL direction failure.
More information on the re-election procedure will be disclosed in the detailed description.
The new D-PE then optionally (and preferably) flushes the forwarding databases (comprising the previously learned Media Access Control addresses or MAC addresses) of the affected VPNs and initiates a MAC flushing message per VPN, ordering this flushing to all the provider nodes where these VPNs were provisioned, to facilitate transition of the traffic, outgoing from the provider to the access network, to the new CE-PE connection. This flush message can use standard means, like the one proposed in ietf-draft-12vpn-ldp-08.txt.
The new D-PE optionally (and preferably) triggers corresponding MAC flushing in the access network as well, to facilitate transition of the traffic, arriving from the access to the provider network, to the new CE-PE connection. This flushing can be triggered by either of the following (1) Reactivating the physical link towards the CE (2) In case of H-VPLS CE-PE connection, reactivation of the former standby spoke PWs towards the CE (3) Re-enabling the sending and receiving traffic through the interface (4) In case the access network runs xSTP, the new D-PE may send an xSTP topology change notification (TCN) to the CE (5) Sending MAC flushing message to the CE. In the absence of MAC flush messages, the traffic would anyway be transitioned to the new CE-PE based on the following ordinary layer 2 Ethernet switching means: (1) MAC address aging (2) MAC address re-learning.
It should be emphasized that, in the proposed technique, only the peer elements (usually, two PEs attached to the CEs) need to participate in the Hello messaging, because the customer traffic is ‘terminated’ there, meaning that these two peer PEs apply MAC address lookup onto an arriving customer packet in order to find out where the packet should go. In other known techniques (for example, Alcatel's), the signaling for dual homing connection is much more extensive—xSTP, contrary to the proposed simple Hello messages, is run among all the CEs and PEs involved (two CEs and two PEs.) The proposed Hello mechanism eliminates signaling interaction between the access and provider networks (xSTP inclusive) required by most of the prior art references to assure a loop-free inter-network connectivity. In fact, both networks need not run xSTP at all, as may be desired when the networks involved are VPLS networks. Moreover, simplicity of the Hello mechanism and its being exchanged between only the peer (usually, two provider) nodes allows switchover times much faster than those of prior art, typically 100-200 ms compared to 1-2 seconds with standard RSTP.
When speaking about the switchover time, it should be noted that in case the VL is protected (say with FRR), it should recover faster than the dual homing configuration decides about switchover due to missing a predetermined number of Hellos at one of the peer elements. In other words, the time it takes to miss the predefined number of Hellos should be larger than the recovery time for a failure in the VL path (e.g., 200 ms compared to 50 ms), in order to avoid an unnecessary switch to a new PE while the Vt is recovering.
The invention will be described in additional details as the description proceeds.
The invention will further be described with references to the following non-limiting drawings, in which:
a,
2
b,
2
c,
2
d illustrate various embodiments of a dual homing configuration and a multi-homing configuration.
a,
3
b,
3
c,
3
d,
3
e,
3
f,
3
g,
3
h illustrate three exemplary scenarios of operation of one specific dual homing configuration.
a schematically illustrates a steady-state operation of an exemplary dual-homing configuration 30 connecting an access Ethernet-based network 32 to a provider Ethernet-based or VPLS network 34 via edge customer nodes CE1, CE2 and edge provider nodes (let them be called peer nodes) PE1, PE2, where CE1 (CE2) is directly connected to PE1 (PE2) via a physical link or spoke PW. PE1 and PE2 may also be connected for the purpose of exchanging customer traffic (in case of a VPLS provider network, there is a PW 36 per VPN between PE1 and PE2). The nodes CE1, CE2 in the access network 32 are connected via a traffic line within the access network, to visualize that if both CE-PE connections are forwarding, then a layer 2 loop will occur in the access network which might not be running xSTP (as is typically the case if the access network is a VPLS network). In such cases the technique proposed by the Inventor is most advantageous. To implement the inventive technique, a bi-directional virtual link VL (38) is established between the nodes PE1 and PE2 for the purpose of Hello signaling.
It is to be noted that the proposed multi-homing configuration (the dual-homing one 30 in this case) is provisioned per each specific access network to be connected to another (say, provider) network, and the suitable procedures (which will be described below) should be implemented per each multi-homing configuration.
The configuration 30 in
For the configuration 30 to work loop-free, at least one CE-PE connection and at least one direction of the VL 38 must be operational, i.e. fault free. Therefore, the VL 38 is preferably protected (e.g., with MPLS FRR mechanism) against failure of an intermediate node or link along the VL, to increase its reliability. The VL is preferably implemented as a dedicated pseudo-wire (PW) in case of VPLS provider network. VL can even be a physical link, as long as the Hello signaling can be exchanged between the peer PEs.
The bi-directional VL 38 serves for periodically exchanging Hello messages (so-called Hellos) between the gateway PEs, to elect the designated forwarder (D-PE) as described below and thus to establish and maintain a loop-free dual homing.
The D-PE can be elected based on a dedicated or conventional identification sent in the Hello message and unambiguously identifying each peer (i.e., the two peers have different identifications so this can serve to elect the D-PE unambiguously). An example for a conventional identification could be the IP address of the PE being a router-switch where a D-PE could be selected based on having a higher (or a lower) IP address. The PEs establish an agreement regarding the elected D-PE, this agreement is suitably indicated in the Hello messages. In a rare case where the IP address of any of the peer elements is changed, the D-PE will be automatically re-elected. (
b,
3
c,
3
d,
3
f,
3
g,
3
h show how the proposed dual-homing configuration 30 will operate in cases of a single fault or multiple simultaneous faults within the configuration.
b illustrates a group of scenarios where the traffic line associated with the designated peer element (D-PE) fails due to failure of at least one of its components (marked with three crosses on CE1, CE1-PE1 connection and PE1 respectively). It is also possible that one direction of the VL 38 fails (marked with an additional cross).
The status of the traffic line becomes known to the D-PE and is normally introduced in the Hello messages sent from the D-PE. When its associated CE-PE connection fails, the PE1 starts sending Hello messages provided with a defect indication (DI). (The PE1 would clear the DI from the Hello messages a predefined time after these failures are repaired). In case the D-PE itself fails, it stops sending Hello messages to the N-PE (PE2). When N-PE receives a DI over the VL or when it fails to receive a predefined number of consecutive Hellos from the D-PE, it becomes a D-PE itself and puts its CE2-PE2 connection into a forwarding state. The alternative connection CE1-PE1 is anyway non-operational, and thus the failure of the VL in the direction from PE2 to PE1 cannot keep PE1 as D-PE.
The new D-PE may optionally and preferably flush the forwarding databases (learned MAC addresses) of the affected VPNs of the access network and initiate a MAC flushing message per VPN ordering this flushing to all the provider nodes where these VPNs were provisioned. This operation is schematically illustrated by a batch of arrows 31. The new D-PE (PE2) may optionally and preferably trigger such MAC flushing (33) also in the access network, using one of the previously suggested methods (e.g., sending xSTP TCN or MAC flush message or by activating the standby spoke PW per VPN).
c illustrates a situation which differs from that in
d illustrates a situation where both CE-PE connections are operational and the virtual link fails in the direction to the D-PE. PE1 thus remains D-PE as it does not receive Hellos from PE2.
e illustrates a situation which differs from that in
f illustrates a situation which differs from that in
g illustrates a situation which differs from that in
h illustrates a situation which differs from that in
The above examples demonstrate that the proposed method and the suitable dual homing configuration are able to function correctly even if only one traffic line of the configuration is in order and/or only one direction of the virtual link VL is operational.
In both states I and II (illustrated as boxes 41 and 45 respectively), the PE normally sends and receives Hellos over the virtual link. The PE must also detect faulty conditions of its own CE-PE connection. (Note that neither Hello messages, nor any alarms of faulty conditions such as “DI”, “Peer Down” and “CE-PE down” are indicated themselves in the state diagram of
Upon initialization (e.g., power up, arrow 40), our PE starts at state I (box 41). If its CE-PE is non-operational (i.e., faulty, down), that is considered the highest priority event “1”. In response, the PE stays in this same state I and sends a defect indication DI in its Hellos. It is then ineligible to be a D-PE. While in State I, a PE sends Hellos, indicating itself as the N-PE. While in State I, in the absence of the highest priority event “1”, if the PE receives information on the second priority event “2”, it moves to state II (arrow 44), and optionally triggers MAC flushing in the provider and the access networks. The second priority event “2” is stated when our PE receives:
State II (box 45) is characterized in that our PE puts its CE-PE connection in the forwarding state, and sends Hellos indicating itself as the designated peer D-PE.
When our PE is in state II, and its CE-PE connection fails, it is considered the highest priority event “1” and the PE returns to state I (arrow 46). Otherwise (in the absence of the highest priority event), if our PE receives information about events of priority “2” such as: DI from its peer in Hello messages, or its peer is down (detected by failing to receive a predefined number of Hellos from its peer), our PE stays in state II (arrow 48). In the absence of events of priorities “1” and “2”, our PE may receive information on events of priority “3”: its peer is elected as D-PE (as would be the case if the peer has, say, a higher IP address), or there is no agreement who is the D-PE (as would be the case if its peer does not receive Hellos and becomes a D-PE even if its IP address indicates it should be N-PE). In this case, our PE returns to state I (arrow 50). If none of the above-mentioned events takes place, our PE stays in state II.
It should be noted that exactly the same state diagram describes the behavior of the peer element of our PE, just when one of them is in state I, the second one would normally be in state II.
It should be appreciated that other modifications of the proposed multi-homing configurations can be proposed, other suitable versions of the method/software product can be developed and they are to be considered part of the invention. The invention is generally defined below by the following claims, and can be interpreted using the above description.
| Number | Date | Country | Kind |
|---|---|---|---|
| 176330 | Jun 2006 | IL | national |
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IL2007/000697 | 6/10/2007 | WO | 00 | 12/15/2008 |
