US20100238813A1 - Q-in-Q Ethernet rings - Google Patents
Q-in-Q Ethernet rings Download PDFInfo
- Publication number
- US20100238813A1 US20100238813A1 US11/477,975 US47797506A US2010238813A1 US 20100238813 A1 US20100238813 A1 US 20100238813A1 US 47797506 A US47797506 A US 47797506A US 2010238813 A1 US2010238813 A1 US 2010238813A1
- Authority
- US
- United States
- Prior art keywords
- ring
- node
- traffic
- path
- working
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/06—Management of faults, events, alarms or notifications
- H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
- H04L41/0668—Management of faults, events, alarms or notifications using network fault recovery by dynamic selection of recovery network elements, e.g. replacement by the most appropriate element after failure
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
- H04L12/437—Ring fault isolation or reconfiguration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
- H04L12/4645—Details on frame tagging
- H04L12/465—Details on frame tagging wherein a single frame includes a plurality of VLAN tags
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/42—Loop networks
- H04L2012/421—Interconnected ring systems
Definitions
- the present invention relates generally to Ethernet and, in particular, to Ethernet rings for Metro Area Networks.
- Ethernet Because of its “flood-and-learn” nature, standard Ethernet (IEEE 802.3) is generally unsuitable for network topologies where there is more than one path between any two nodes. The existence of a parallel path creates a loop around which the Ethernet frames circle endlessly, thus overburdening the network. Therefore, Ethernet is best suited to a tree topology rather than a ring. However, ring topologies are desirable for deploying Ethernet in Metro Area Networks where ring topologies are desirable, e.g. for resiliency.
- Ethernet rings are prone to endlessly loop unless protocols such as IEEE 802 .lD Spanning Tree Protocol (STP) or IEEE 802.1W Rapid Reconfiguration are used to detect and disable parallel branches that create loops. While Spanning Tree Protocol and Rapid Reconfiguration can eliminate loops on Ethernet rings, these protocols introduce recovery lags in the order of tens of seconds, i.e. the time to recover from a fault in the ring is unacceptably high for customers who expect seamless connectivity and undetectable fault correction. In other words, customers expect connectivity to be restored within approximately 50 ms (like SONET does).
- STP Spanning Tree Protocol
- Rapid Reconfiguration can eliminate loops on Ethernet rings
- these protocols introduce recovery lags in the order of tens of seconds, i.e. the time to recover from a fault in the ring is unacceptably high for customers who expect seamless connectivity and undetectable fault correction. In other words, customers expect connectivity to be restored within approximately 50 ms (like SONET does).
- a further shortcoming of current Ethernet ring technology as defined in 802.17 is that the MAC-PHY chip that determines which direction to send traffic around the ring is a specialized component where innovation and available bandwidth typically lags other, simpler, Ethernet PHY implementations. Thus, even if all the other components of the Ethernet switches are capable of handling higher rates, as is currently achievable, the ring MAC-PHY chip limits the overall bit-rate of the ring.
- An aspect of the present invention is to provide a simple, resilient and high-speed virtual ring for frame-based traffic such as Ethernet that redresses one or more of the deficiencies in the prior art as described above.
- the resilient virtual ring has a plurality of nodes interconnected by working and protection virtual paths.
- the virtual ring will have a working path in which traffic flows in one direction, and a protection path in which the traffic flows in the opposite direction. It is conceivable to have multiple virtual rings which have the same routing for the working path and for the protection paths. It is similarly possible to envision multiple virtual rings where the routing is a mirror image, the routing of one or more rings protection path corresponding to the routing of the working path or path of other rings.
- Each virtual ring implements a unique Ethernet broadcast domain.
- Each virtual ring is implemented via configured connectivity for a set of VLANs.
- Traffic upon insertion into the ring is tagged using ring tags which serve to identify the originating station on the ring and are associated with the specific broadcast domain. These tags are removed when the traffic leaves the ring.
- these ring tags are VLAN IDs (VIDS) and the insertion of VLAN tags is described in IEEE standard 802.1ad.
- VIPDS VLAN IDs
- the ingress node tags the traffic with a working-path VID which also identifies the entry point to the ring.
- the virtual ring mechanism uses VLAN tagging, and configured VLAN forwarding. This behaviour can be deployed on nodes in conjunction with other styles of Ethernet forwarding such as spanning tree or static configuration of MAC tables via simply partitioning the VLAN space.
- Ring nodes perform normal Ethernet bridging operations, in particular populating the forwarding database via source learning.
- traffic in each broadcast domain is distinguished by a plurality of VLAN IDs (one per ring node for each of the working and protection paths)
- Shared VLAN Learning permits the set of ring nodes to use a common set of learned MAC forwarding information.
- “port aliasing” is performed to record a port direction that is opposite to the port direction that would normally be learned by the node in traditional bridge operation.
- ELAN Emulated LAN
- MAC addresses are only learned in one direction around the ring, i.e. on the working path.
- a packet observed as arriving on one ring port has source learning recorded as if the packet arrived on the other ring port.
- the ring physically attaches to the node via two distinct ports, it logically appears as a single port.
- MAC learning is disabled on all protection-path VIDs.
- each node has a cross-connect for cross-connecting the working path to the protection path, which is implemented by VLAN translation, the working VLAN is mapped 1:1 to a protection VLAN forwarded in the reverse direction to the working path.
- VLAN translation the working VLAN is mapped 1:1 to a protection VLAN forwarded in the reverse direction to the working path.
- the traffic is then carried over the protection path all the way to the second of the two end nodes immediately adjacent the failure whereupon the traffic is cross-connected back onto the working path for egress from the working path.
- “learned” forwarding information used for destination stripping, and tag information associated with source stripping is fully applicable independent of the fault status of the ring, and a ring failure is transparent to all nodes not immediately adjacent to the failure (which perform the selector operation of mapping the working to the protection paths).
- an aspect of the present invention provides a method of routing frame-based traffic over a resilient virtual ring having a commonly routed working path and a protection path per ring node.
- the method includes the steps of defining, for each node of the ring, a plurality of unique ring tags that uniquely identify each one of the nodes and whether the working path or the protection path is to carry the traffic, and tagging frames in the virtual ring with one of the ring tags to uniquely identify both the node that has tagged the frames and whether the traffic is being carried over the working path or the protection path.
- the frame-based traffic can be Ethernet, in which case the ring tags are VLAN IDs (VIDs) that are tagged to the Ethernet frames using Q-in-Q VLAN stacking.
- VIDs VLAN IDs
- Another aspect of the present invention provides a resilient virtual ring having a plurality of nodes interconnected by a working path and a protection path, each of the plurality of nodes including ingress and egress ports for frame-based traffic entering and leaving the virtual ring, wherein each node comprises a plurality of ring tags for uniquely tagging traffic in the ring, the ring tags identifying both the node that has tagged the traffic and whether the traffic is carried by the working path or the protection path.
- the frame-based traffic are Ethernet frames
- Q-in-Q VLAN stacking enables tagging of the frames with unique VLAN IDs (VIDs).
- FIG. 1A is a schematic illustration of an Ethernet VLAN ring configured for 1:1 protection for ELAN or Source Specific Broadcast (SSB) in accordance with an embodiment of the present invention
- FIG. 1B is an enlarged schematic illustration of Node A of FIG. 1A operating in a fault-free state
- FIG. 1C is an enlarged schematic illustration of Nodes B, C and D of FIG. 1A operating in a fault-free state;
- FIG. 2B is a schematic illustration of the operation of Node C during ring folding
- FIG. 2C is a schematic illustration of the operation of Node D during ring folding
- FIG. 3A is a schematic illustration of an Ethernet VLAN ring configured for 1:1 protection for SSM in accordance with another embodiment of the present invention
- FIG. 3B is an enlarged schematic illustration of Node A of FIG. 3A operating in a fault-free state
- FIG. 3C is an enlarged schematic illustration of Nodes B, C and D of FIG. 3A operating in a fault-free state;
- FIG. 4B is a schematic illustration of the operation of Node C during ring folding
- FIG. 4C is a schematic illustration of the operation of Node D during ring folding
- FIG. 5A is a schematic illustration of an Ethernet VLAN ring configured for 1+1 protection in accordance with another embodiment of the present invention.
- FIG. 5B is an enlarged schematic illustration of Node A of FIG. 5A operating in a fault-free state
- FIG. 5C is an enlarged schematic illustration of Nodes B, C and D of FIG. 5A operating in a fault-free state
- FIG. 6 is a schematic illustration of an Ethernet ring node in accordance with an embodiment of the present invention.
- the present invention provides both a resilient, virtual ring for frame-based traffic such as, preferably, Ethernet as well as a method of routing frame-based (e.g. Ethernet) traffic over a resilient, virtual ring.
- frame-based traffic such as, preferably, Ethernet
- a method of routing frame-based (e.g. Ethernet) traffic over a resilient, virtual ring e.g. Ethernet
- a resilient, virtual Ethernet ring designated generally by reference numeral 10 in FIG. 1A has a plurality of nodes (labelled A, B, C and D) interconnected by a working path 12 and a protection path 14 per ring node, FIG. 1A being an exemplar of a single instance of what would be replicated once per node on the ring.
- Each path being implemented via VLAN configuration (the blocking and unblocking of ports).
- the virtual ring can be virtualized from a non-ring topology such as a mesh; in other words, there does need to be an actual physical ring architecture for implementation of this virtual ring.
- four nodes are illustrated, this is merely presented by way of example, i.e. the number of nodes on the ring can vary.
- Each of the plurality of nodes A-D may include ingress ports and egress ports for traffic entering and leaving the virtual ring, respectively.
- the virtual ring may transit nodes which do not have ingress/egress ports but do participate in ring behaviour.
- Associated with each node is a set of ring tags for tagging the frames of traffic in the ring.
- a plurality of unique ring tags are defined for each node of the ring. The ring tags identify whether the associated ring path is the working path or the protection path and the unique identity of the ring node on that path.
- VLAN tags one per ring station
- a corresponding set of tags is associated with the protection path of a unidirectional ring.
- the routing of the protection path being congruent with the working path, the forwarding direction is thus simply the reverse of that of the working path.
- the ring tags are virtual local area network identifiers or VLAN IDs (VIDs) for tagging Ethernet frames in the ring.
- VIDs virtual local area network identifiers
- each node in the ring has a unique set of W-VID and P-VID identifiers that are used to tag traffic in the ring so as to identify the node that has tagged the traffic as well as which of the working path and protection path is carrying the traffic.
- the VIDs identify both a specific virtual ring (i.e. in a trivial topology case “east” or “west”), whether the traffic is carried on the working path or on the protection path, and the node originating traffic onto that ring. It should be noted that, as the technique permits the virtualization of VLAN tagged rings, a node could conceivably participate in many disjoint virtual rings and be provisioned with a corresponding set of VLAN tags to participate in each ring.
- the expression “west”, “westward” or “westbound” shall mean clockwise around the ring whereas the expressions “east”, “eastward” or “eastbound” shall mean counter-clockwise around the ring.
- the virtual Ethernet ring is constructed so that traffic entering the ring is forwarded along the working path, and may only leave the ring via the working path, traffic on the protection path is constrained to the ring to prevent undesirable duplication to off-ring nodes. Traffic is never inserted directly into the protection path, so the fact that it is an uninterrupted ring with no egress is a non-issue. Traffic is only cross-connected onto the protection path when the ring structure has been broken due to a fault.
- the frame-based traffic entering a given node is tagged with a VID that identifies that the traffic is being inserted onto the working path and the point of insertion.
- each packet entering the ring is tagged with a unique VID identifying to the switch fabric that the traffic is to be inserted onto the working path of a specific virtual ring. Since the working path is unidirectional, no routing decision needs to be made at the ingress node, which therefore obviates the need for a direction-determining MAC-PHY chip at the ingress node which, as noted above, is not only an expensive component but only limits bit-rate. It should be noted that VLANs are bi-directional, but uni-directionality is an artefact of how VLANs are used to create ring paths.
- the ingress node since the traffic entering the ring is tagged with a VID that is unique, and port blocking for that VID is performed on the return port for the virtual ring, the ingress node will perform “source stripping”, i.e. discarding traffic that has returned “unclaimed” to the ingress node. In other words, traffic is discarded (stripped out) if none of the other nodes in the ring recognize the destination MAC address or if the packet was intended to be replicated to all ring nodes. In other words, if traffic has circled back around the entire ring without being claimed by any other node, then it is discarded by the ingress node (because the working VLAN is blocked on the port of return). Thus, the ingress node discards received traffic that is tagged with the ring tag assigned by the ingress node when the traffic first entered the ring.
- Source stripping thus ensures that traffic does not loop endlessly around the ring. If another node on the ring recognizes the MAC address as being one that is served by that node, then the node (acting as an “egress node”, that is) forwards the packet to a non-ring port.
- the actual forwarding behaviour of ring nodes is that of standard 802 bridge forwarding. Broadcast, multicast and unknown packets are forwarded on both ring ports and replicated on local non-ring ports which are configured to participate in the ring broadcast domain.
- a ring node may have a MAC forwarding entry for a given destination address that points to a ring port or points to an off-ring port. In the scenario where a MAC forwarding entry exists for an “off-ring” port, the ring node will (as an artefact of normal bridge operation) perform “destination stripping” such that the packet only traverses a portion of the overall ring.
- each node also includes a “port aliasing module” for receiving the learned MAC addresses and for recording in the forwarding table a port direction that is opposite to an actual port direction detected by the node.
- a “port aliasing module” for receiving the learned MAC addresses and for recording in the forwarding table a port direction that is opposite to an actual port direction detected by the node.
- the ring/broadcast domain is unidirectional, it logically is a single port but in actual implementation is an ingress and an egress.
- Normal Ethernet source learning will attempt to associate learned MAC addresses of traffic received from other ring nodes with the ingress port, while the desirable behaviour is to actually associate the forwarding for those MAC addresses to the egress port for the ring as the only viable path around the ring is unidirectional.
- Port aliasing permits the translation of learned information from ingress to egress prior to forwarding of traffic. This may be done prior to or subsequent to insertion of learned information into the local forwarding database. Precisely when
- FIG. 1A is a schematic illustration of an Ethernet VLAN ring configured for 1:1 protection for Emulated LAN (ELAN) or Source Specific Broadcast (SSB) in accordance with an embodiment of the present invention.
- the ring 10 has working and protection paths interconnecting four nodes A, B, C and D.
- traffic inserted at A is tagged with a Working VID (W-VID) corresponding to a configured working path routed A, B, C, D.
- W-VID Working VID
- P-VID protection VID
- the VIDs are referenced with respect to Node A.
- VID can further identify which of the two directions around the ring the traffic is carried.
- a West Working VID, West Protection VID, East Working VID and East Protection VID are defined for each node and, depending on which of the two directions is arbitrarily chosen for the working path, either the west VIDs or the east VIDs are used.
- FIG. 1C is an enlarged schematic illustration of Nodes B, C and D of FIG. 1A operating in a fault-free state.
- Nodes B, C and D pass the P-VID (as did Node A) but these nodes pass the W-VID and takes a copy, removing the ring tag (VID) when the traffic is taken off the ring.
- VID ring tag
- the virtual Ethernet ring is made resilient (or “fault-tolerant”) by virtue of its ring topology (which is an inherently resilient topology because it is capable of ring folding to isolate a span failure), the presence of a protection path providing 1:1 protection, and the presence of cross-connects at each node that are capable of “hairpinning” the traffic when the ring folds, as is explained in the following paragraphs.
- the ring 10 can fold in response to a span failure 16 by cross-connecting the working path 12 and the protection path 14 at the two “end nodes” 18 , 20 immediately on either side of the span failure.
- This will be referred to herein as “hairpinning” since the traffic takes what can be visualized as a “hairpin curve” (as shown in FIG. 2A ) as it is switched from the working path onto the protection path at the first end node 18 , i.e. the last node that the traffic encounters on the working path just before the span failure.
- the traffic is then carried all the way back to the second end node 20 on the protection path (in the opposite direction) at which point this same traffic is then “hairpinned” again (i.e.
- the failed span provides the “selector” synchronization mechanism for the protection switch.
- the net effect of the cross connecting at both ring nodes adjacent to the failure is that the protection path acts as a “bypass” to loop the traffic back to the working path while preserving the unidirectionality of the ring. Folding the ring using this double-hairpin arrangement not only preserves the unidirectionality of the working path but also ensures that traffic can only ingress or egress the ring from the working path. In other words, the working path always remains the working path even after a span fault.
- FIGS. 3A-3C and FIGS. 4A-4C illustrate respectively the operation and folding of a virtual Ethernet ring configured for 1:1 protection to enable Source-Specific Multicast (SSM).
- SSM Source-Specific Multicast
- the configuration of connectivity is constrained such that only the source node (termed root)has connectivity to all other ring nodes (termed leaves), i.e. the other ring nodes can only communicate with the source.
- the SSM head-end only needs to know that a given ring node is interested, but does not need to know which one.
- Two working VIDs are required, one for the head-end to the leaves, and the other for the leaves to the head-end.
- the working path 12 has a protection path 14 , and the return path 22 is protected by a protection return 24 .
- VIDs can be designated as follows: Working (W-VID), Working Return (WR-VID), Protection (P-VID) and Protection Return (PR-VID).
- Node A operates in a fault-free state by passing P-VID and PR-VID while blocking W-VID on the east port. Traffic entering the ring at Node A is tagged with W-VID and sent onto the ring via the west port of Node A (assuming, for this example, a westward working direction) while return traffic is taken off the ring on WR-VID.
- Nodes B, C and D operate in a fault-free state by also passing P-VID and PR-VID.
- the node passes W-VID and takes a copy (stripping the VID as the traffic egresses the ring).
- Each of these nodes also passes WR-VID and inserts traffic onto W-VID by assigning a ring tag (W-VID).
- the Ethernet ring 10 folds in response to a failure 16 in the span, e.g. between Nodes C and D.
- Node C (the first end node 18 ) cross-connects W-VID to P-VID and WR-VID to PR-VID (to thus effect a port egress translation).
- Node D (the second end node 20 ) cross-connects P-VID to W-VID (to thus effect a port ingress translation).
- a highly resilient, unidirectional, virtual Ethernet ring can be created having one protection path per working path, thus providing 1:1 protection for either ELAN and SSB implementations or an SSM implementation.
- a 1 + 1 protection arrangement can be implemented by sending (“bi-casting”) traffic in opposite directions on both the working and protection paths 12 , 14 of the ring 10 .
- the ingress node not only sends the same traffic (i.e. the same frames) in opposite directions around the ring, but it also sends Connectivity Fault Management (CFM) heartbeats in both directions around the ring.
- CFM heartbeats enable a destination node on the ring to select one of the two received copies of the bi-cast traffic based on the characteristics of the CFM heartbeats received at the destination node.
- Node A adds ring tags as traffic enters the ring as is bi-cast onto both the W-VID and P-VID. Node A also blocks P-VID and W-VID on the east port.
- each one of Nodes B, C and D has a selector that uses IEEE 802.1ag and G.8031 to select which of the two sets of bi-cast traffic it will treat as the working-path traffic. The VID is stripped when traffic exits the ring. Each node passes W-VID and takes a copy. Each node also passes P-VID and takes a copy.
- a range of VLANs is delegated to the operation of the ring, and the appropriate ring connectivity is configured via configuring of port membership for the VLAN set on each ring node.
- Each node may then self-discover and seize a set of unique ring tags (the subset of tags in the range delegated to the ring that will be used by the specific ring node).
- ring tags are randomly selected and tested. To test the ring tags, the node attempts to ping itself with a frame tagged with the selected working path ring tag. If the ring tag is not in use by any node in the ring, the node will be able to ping itself (i.e. there is uninterrupted connectivity around the ring).
- the node will not be able to ping itself because the actual owner of that selected working ring tag (i.e. another node) will have blocked the port for that ring tag in order to do source stripping.
- each node would need to seize two unique VIDS.
- VID discovery and seizing is done by randomly selecting a potentially usable VID associated with a specific ring at each node being initialized, sending the potentially usable VID around the ring to try to ping oneself and then seizing the VID if it returns unclaimed to the node that sent the VID. These steps are repeated until the node being initialized has pinged itself at least twice. The seizing is complete when a block of 2 VIDs are “owned” by the node being initialized.
- a given node should wait a random period of time before selecting a ring tag and attempting to ping itself.
- the node should ping itself a couple of times with the same ring tag to be certain that the VID is truly not in use and thus can legitimately be seized.
- the node seizes a ring tag, it modifies the configuration for the seized range of ring tags from the default to the owned state.
- FIG. 6 schematically illustrates, by way of example only, an Ethernet ring node (“Node X”) in accordance with an embodiment of the present invention.
- Node X has a routing switch 30 (e.g. Nortel 8608 or equivalent) and a switch fabric module 40 (e.g. Nortel 8692 or equivalent).
- the routing switch 30 has an ingress port 32 and an egress port 34 for traffic entering and exiting the ring.
- the routing switch 34 includes a mapping module 36 (or other such means) for mapping a C-VID (Customer VID) received on the ingress port to a ring VID and pushing the frames to the switch fabric module 40 .
- the routing switch 34 also includes a VID-stripping module 38 (or other such means) for stripping the ring VID from the traffic before it exits the ring via the egress port 34 .
- the switch fabric module 40 includes forwarding memory 42 , a port, aliasing module 44 , and a 802 .lQ bridge 46 .
- the memory 42 maintains the forwarding table, e.g. the Forwarding Information Base, into which MAC addresses and port directions are stored.
- the port aliasing module 44 stores a port direction that is opposite to the actual learned direction. This port aliasing preserves the unidirectionality of the ring. Traffic is switched by the .1Q bridge 48 onto either the West PHY 50 or the East PHY 52 .
- the ring is able to support a variety of Ethernet applications, including ELINE, E-TREE, Emulated LAN (ELAN), Source-Specific Multicast (SSM), and Source-Specific Broadcast (SSB).
- ELINE and E-TREE the ring serves as a Provider Backbone Bridge (PBB) within a Provider Backbone Transport (PBT) network, which are described in U.S. Patent Application Publication 2005/0220096 entitled TRAFFIC ENGINEERING IN FRAME-BASED CARRIER NETWORKS published Oct. 6, 2005, which is hereby incorporated by reference.
- the PBT provides e2e PS (end-to-end protection switching) so the ring must not interfere with the PBT VID range.
- the ring operates as a resilient distributed switch.
- the ring acts to resiliently fan out a dynamically varying set of (S,G) multicast groups to a set of ring nodes.
- the ring must also provide a constrained return path for IGMP snooping/filtering.
- the ring acts to resiliently fan out an invariant bundle of (S,G) multicast groups to a set of ring nodes, but unlike SSM, no return path is required.
- the virtual ring should be able to support all of these applications simultaneously.
- a range of VIDs is designated for each type of application or “behaviour”, i.e. a range of VIDs is designated for ELAN, another range of VIDs for SSM and yet another range of VIDs for SSB.
- the default is for each node to pre-configure each range and then, as required, seize specific VIDs in each range.
- ELINE such as Provider Backbone Transport, which offers its own end-to-end resiliency
- VID range is assigned.
- Emulated LAN can be enabled by specifying, in a generalized case, only two VIDs per ring node, namely a Working VID (W-VID) and a Protection VID (P-VID).
- W-VID Working VID
- P-VID Protection VID
- four VIDs are defined per ring node, e.g. a West Working VID, a West Protection VID, an East Working VID and an East Protection VID.
- Each node needs to both relay and take a copy of Working VIDs.
- Each node simply needs to connect Protection VIDs between ring ports.
- MAC learning is disabled on the Protection VIDs.
- Source Specific Multicast can be enabled by specifying four VIDs per SSM ring (for the generalized case), i.e. a Working VID, Working Return VID, Protection VID and Protection Return VID. Each node needs to both relay and take a copy of Working VIDs. Each node needs to connect Protection and Working Return VIDs together. MAC learning is disabled on all VIDs.
- Source Specific Broadcast can be enabled by specifying two VIDs per source node (W-VID and P-VID) per ring. Each node needs to both relay and take a copy of Working VIDS. Each node simply needs to connect Protection VIDs between ring ports. MAC learning is disabled on all VIDs.
Abstract
Description
- This is the first application filed for the present invention.
- The present invention relates generally to Ethernet and, in particular, to Ethernet rings for Metro Area Networks.
- Because of its “flood-and-learn” nature, standard Ethernet (IEEE 802.3) is generally unsuitable for network topologies where there is more than one path between any two nodes. The existence of a parallel path creates a loop around which the Ethernet frames circle endlessly, thus overburdening the network. Therefore, Ethernet is best suited to a tree topology rather than a ring. However, ring topologies are desirable for deploying Ethernet in Metro Area Networks where ring topologies are desirable, e.g. for resiliency.
- Deployment of large (metro area) Ethernet rings is hindered, however, by the fact that Ethernet rings are prone to endlessly loop unless protocols such as IEEE 802.lD Spanning Tree Protocol (STP) or IEEE 802.1W Rapid Reconfiguration are used to detect and disable parallel branches that create loops. While Spanning Tree Protocol and Rapid Reconfiguration can eliminate loops on Ethernet rings, these protocols introduce recovery lags in the order of tens of seconds, i.e. the time to recover from a fault in the ring is unacceptably high for customers who expect seamless connectivity and undetectable fault correction. In other words, customers expect connectivity to be restored within approximately 50 ms (like SONET does).
- A further shortcoming of current Ethernet ring technology as defined in 802.17 is that the MAC-PHY chip that determines which direction to send traffic around the ring is a specialized component where innovation and available bandwidth typically lags other, simpler, Ethernet PHY implementations. Thus, even if all the other components of the Ethernet switches are capable of handling higher rates, as is currently achievable, the ring MAC-PHY chip limits the overall bit-rate of the ring.
- Thus, it remains highly desirable to provide a simple, resilient and high-speed virtual ring for frame-based traffic such as Ethernet, particularly for Metro Area Networks.
- An aspect of the present invention is to provide a simple, resilient and high-speed virtual ring for frame-based traffic such as Ethernet that redresses one or more of the deficiencies in the prior art as described above. The resilient virtual ring has a plurality of nodes interconnected by working and protection virtual paths. The virtual ring will have a working path in which traffic flows in one direction, and a protection path in which the traffic flows in the opposite direction. It is conceivable to have multiple virtual rings which have the same routing for the working path and for the protection paths. It is similarly possible to envision multiple virtual rings where the routing is a mirror image, the routing of one or more rings protection path corresponding to the routing of the working path or path of other rings. It is similarly possible to consider a node to simultaneously be a ring node on several topologically disjoint rings at the same time. Each virtual ring implements a unique Ethernet broadcast domain. Each virtual ring is implemented via configured connectivity for a set of VLANs. Traffic upon insertion into the ring is tagged using ring tags which serve to identify the originating station on the ring and are associated with the specific broadcast domain. These tags are removed when the traffic leaves the ring. For Ethernet, these ring tags are VLAN IDs (VIDS) and the insertion of VLAN tags is described in IEEE standard 802.1ad. When traffic enters the ring, the ingress node tags the traffic with a working-path VID which also identifies the entry point to the ring.
- It should be noted that the virtual ring mechanism uses VLAN tagging, and configured VLAN forwarding. This behaviour can be deployed on nodes in conjunction with other styles of Ethernet forwarding such as spanning tree or static configuration of MAC tables via simply partitioning the VLAN space.
- Ring nodes perform normal Ethernet bridging operations, in particular populating the forwarding database via source learning. Although traffic in each broadcast domain is distinguished by a plurality of VLAN IDs (one per ring node for each of the working and protection paths), Shared VLAN Learning (SVL) permits the set of ring nodes to use a common set of learned MAC forwarding information. In order to preserve directionality around the ring, “port aliasing” is performed to record a port direction that is opposite to the port direction that would normally be learned by the node in traditional bridge operation. For example, in an Emulated LAN (ELAN) implementation, MAC addresses are only learned in one direction around the ring, i.e. on the working path. A packet observed as arriving on one ring port has source learning recorded as if the packet arrived on the other ring port. In this way, although the ring physically attaches to the node via two distinct ports, it logically appears as a single port. For ELAN, MAC learning is disabled on all protection-path VIDs.
- Traffic only ingresses or egresses the ring via the working path. This is achieved by standard VLAN configuration such that off-ring ports associated with the ring broadcast domain are not blocked for the set of working VLANs associated with the ring. Copies of broadcast, multicast or packets for which the path to the destination is unknown by the ring nodes will typically egress the ring at all ports associated with the ring broadcast domain. A copy of such packets will traverse the ring back to the node of origin where the ring tag allows such packets to be identified as having circumnavigated the ring and consequently discarded at the originating node (termed “source stripping”). Packets directed around the ring may also encounter ring nodes which have “learned” off-ring connectivity, at which point the packet will be removed from the ring and forwarded to the off-ring destination (termed “destination stripping”).
- In the event of a failure in a span between two nodes in the ring, the ring folds as a resiliency mechanism to isolate the failed span. To enable ring folding, each node has a cross-connect for cross-connecting the working path to the protection path, which is implemented by VLAN translation, the working VLAN is mapped 1:1 to a protection VLAN forwarded in the reverse direction to the working path. Thus, if a span fails, the two end nodes immediately adjacent to the span failure isolate the failure by cross-connecting their working and protection paths. This cross-connection folds the ring to thus transfer traffic from the working path onto the protection path at the first of the two end nodes immediately adjacent the failure. The traffic is then carried over the protection path all the way to the second of the two end nodes immediately adjacent the failure whereupon the traffic is cross-connected back onto the working path for egress from the working path. In this way, “learned” forwarding information used for destination stripping, and tag information associated with source stripping is fully applicable independent of the fault status of the ring, and a ring failure is transparent to all nodes not immediately adjacent to the failure (which perform the selector operation of mapping the working to the protection paths).
- Therefore, existing specified bridge implementations employing the tagging of ring traffic using Q-in-Q stacking, VLAN translation and by using Shared VLAN Learning in combination with port aliasing (to permit source learning to be applied to a broadcast domain implemented as a unidirectional ring path), a virtual Ethernet ring can be constructed that does not suffer from the shortcomings that hamper prior-art implementations. Moreover, the ring is made resilient by virtue of the cross-connects at each node which allow the ring to fold to isolate a span failure. Even once the ring has folded, traffic continues to ingress to or egress from the working path only.
- Accordingly, an aspect of the present invention provides a method of routing frame-based traffic over a resilient virtual ring having a commonly routed working path and a protection path per ring node. The method includes the steps of defining, for each node of the ring, a plurality of unique ring tags that uniquely identify each one of the nodes and whether the working path or the protection path is to carry the traffic, and tagging frames in the virtual ring with one of the ring tags to uniquely identify both the node that has tagged the frames and whether the traffic is being carried over the working path or the protection path.
- The frame-based traffic can be Ethernet, in which case the ring tags are VLAN IDs (VIDs) that are tagged to the Ethernet frames using Q-in-Q VLAN stacking.
- Another aspect of the present invention provides a resilient virtual ring having a plurality of nodes interconnected by a working path and a protection path, each of the plurality of nodes including ingress and egress ports for frame-based traffic entering and leaving the virtual ring, wherein each node comprises a plurality of ring tags for uniquely tagging traffic in the ring, the ring tags identifying both the node that has tagged the traffic and whether the traffic is carried by the working path or the protection path. Where the frame-based traffic are Ethernet frames, Q-in-Q VLAN stacking enables tagging of the frames with unique VLAN IDs (VIDs).
- Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
-
FIG. 1A is a schematic illustration of an Ethernet VLAN ring configured for 1:1 protection for ELAN or Source Specific Broadcast (SSB) in accordance with an embodiment of the present invention; -
FIG. 1B is an enlarged schematic illustration of Node A ofFIG. 1A operating in a fault-free state; -
FIG. 1C is an enlarged schematic illustration of Nodes B, C and D ofFIG. 1A operating in a fault-free state; -
FIG. 2A is a schematic illustration of how the Ethernet VLAN ring ofFIG. 1A folds in response to a failure in the span between Nodes C and D; -
FIG. 2B is a schematic illustration of the operation of Node C during ring folding; -
FIG. 2C is a schematic illustration of the operation of Node D during ring folding; -
FIG. 3A is a schematic illustration of an Ethernet VLAN ring configured for 1:1 protection for SSM in accordance with another embodiment of the present invention; -
FIG. 3B is an enlarged schematic illustration of Node A ofFIG. 3A operating in a fault-free state; -
FIG. 3C is an enlarged schematic illustration of Nodes B, C and D ofFIG. 3A operating in a fault-free state; -
FIG. 4A is a schematic illustration of how the Ethernet VLAN ring ofFIG. 3A folds in response to a failure in the span between Nodes C and D; -
FIG. 4B is a schematic illustration of the operation of Node C during ring folding; -
FIG. 4C is a schematic illustration of the operation of Node D during ring folding; -
FIG. 5A is a schematic illustration of an Ethernet VLAN ring configured for 1+1 protection in accordance with another embodiment of the present invention; -
FIG. 5B is an enlarged schematic illustration of Node A ofFIG. 5A operating in a fault-free state; -
FIG. 5C is an enlarged schematic illustration of Nodes B, C and D ofFIG. 5A operating in a fault-free state; and -
FIG. 6 is a schematic illustration of an Ethernet ring node in accordance with an embodiment of the present invention. - It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
- In general, and as will be elaborated below with respect to the specific embodiments illustrated in
FIGS. 1-6 , the present invention provides both a resilient, virtual ring for frame-based traffic such as, preferably, Ethernet as well as a method of routing frame-based (e.g. Ethernet) traffic over a resilient, virtual ring. Although the embodiments described below are implemented in Ethernet, it should be understood that the invention could be applied to other frame-based networks. - A resilient, virtual Ethernet ring designated generally by
reference numeral 10 inFIG. 1A has a plurality of nodes (labelled A, B, C and D) interconnected by a workingpath 12 and aprotection path 14 per ring node,FIG. 1A being an exemplar of a single instance of what would be replicated once per node on the ring. Each path being implemented via VLAN configuration (the blocking and unblocking of ports). As will be appreciated by those of ordinary skill in the art, the virtual ring can be virtualized from a non-ring topology such as a mesh; in other words, there does need to be an actual physical ring architecture for implementation of this virtual ring. Furthermore, it should be understood that, while four nodes are illustrated, this is merely presented by way of example, i.e. the number of nodes on the ring can vary. - Each of the plurality of nodes A-D may include ingress ports and egress ports for traffic entering and leaving the virtual ring, respectively. Similarly, the virtual ring may transit nodes which do not have ingress/egress ports but do participate in ring behaviour. Associated with each node is a set of ring tags for tagging the frames of traffic in the ring. In other words, a plurality of unique ring tags are defined for each node of the ring. The ring tags identify whether the associated ring path is the working path or the protection path and the unique identity of the ring node on that path. So a set of VLAN tags (one per ring station) is associated with the working path of a unidirectional ring and a corresponding set of tags is associated with the protection path of a unidirectional ring. The routing of the protection path being congruent with the working path, the forwarding direction is thus simply the reverse of that of the working path.
- In the preferred embodiment, the ring tags are virtual local area network identifiers or VLAN IDs (VIDs) for tagging Ethernet frames in the ring. Thus, in the generalized case, each node in the ring has a unique set of W-VID and P-VID identifiers that are used to tag traffic in the ring so as to identify the node that has tagged the traffic as well as which of the working path and protection path is carrying the traffic. The VIDs identify both a specific virtual ring (i.e. in a trivial topology case “east” or “west”), whether the traffic is carried on the working path or on the protection path, and the node originating traffic onto that ring. It should be noted that, as the technique permits the virtualization of VLAN tagged rings, a node could conceivably participate in many disjoint virtual rings and be provisioned with a corresponding set of VLAN tags to participate in each ring.
- The Ethernet frames can be tagged using Q-in-Q stacking (also written as QinQ). Q-in-Q stacking is an encapsulation protocol defined in IEEE 802.lad which is hereby incorporated by reference.
- For the purposes of this specification, the expression “west”, “westward” or “westbound” shall mean clockwise around the ring whereas the expressions “east”, “eastward” or “eastbound” shall mean counter-clockwise around the ring.
- In the preferred embodiment, the virtual Ethernet ring is constructed so that traffic entering the ring is forwarded along the working path, and may only leave the ring via the working path, traffic on the protection path is constrained to the ring to prevent undesirable duplication to off-ring nodes. Traffic is never inserted directly into the protection path, so the fact that it is an uninterrupted ring with no egress is a non-issue. Traffic is only cross-connected onto the protection path when the ring structure has been broken due to a fault. Thus, in the preferred embodiment, the frame-based traffic entering a given node is tagged with a VID that identifies that the traffic is being inserted onto the working path and the point of insertion. Furthermore, in the preferred embodiment, the ring is said to be “unidirectional” because the working path is unidirectional in the arbitrarily chosen direction around the ring while the protection path is also unidirectional albeit in the opposite direction around the ring. The actual association of traffic from an off-ring point to a particular ring-based broadcast domain is performed by normal Ethernet classification means as specified in 802.lad whereby either tag or port information is used as a ring selector. Similarly a ring node may implement ports wholly not associated with ring behaviour.
- Thus, when traffic enters the ring at a node (hereinafter an “ingress node”), each packet entering the ring is tagged with a unique VID identifying to the switch fabric that the traffic is to be inserted onto the working path of a specific virtual ring. Since the working path is unidirectional, no routing decision needs to be made at the ingress node, which therefore obviates the need for a direction-determining MAC-PHY chip at the ingress node which, as noted above, is not only an expensive component but only limits bit-rate. It should be noted that VLANs are bi-directional, but uni-directionality is an artefact of how VLANs are used to create ring paths. As only a single node may insert traffic tagged with the VID of a specific working VLAN, and that VLAN will be blocked for the port corresponding to the return path once traffic has circumnavigated the ring, there will be only one egress port for the VLAN from the ring node.
- Moreover, since the traffic entering the ring is tagged with a VID that is unique, and port blocking for that VID is performed on the return port for the virtual ring, the ingress node will perform “source stripping”, i.e. discarding traffic that has returned “unclaimed” to the ingress node. In other words, traffic is discarded (stripped out) if none of the other nodes in the ring recognize the destination MAC address or if the packet was intended to be replicated to all ring nodes. In other words, if traffic has circled back around the entire ring without being claimed by any other node, then it is discarded by the ingress node (because the working VLAN is blocked on the port of return). Thus, the ingress node discards received traffic that is tagged with the ring tag assigned by the ingress node when the traffic first entered the ring.
- Source stripping thus ensures that traffic does not loop endlessly around the ring. If another node on the ring recognizes the MAC address as being one that is served by that node, then the node (acting as an “egress node”, that is) forwards the packet to a non-ring port. It should be noted that the actual forwarding behaviour of ring nodes is that of standard 802 bridge forwarding. Broadcast, multicast and unknown packets are forwarded on both ring ports and replicated on local non-ring ports which are configured to participate in the ring broadcast domain. A ring node may have a MAC forwarding entry for a given destination address that points to a ring port or points to an off-ring port. In the scenario where a MAC forwarding entry exists for an “off-ring” port, the ring node will (as an artefact of normal bridge operation) perform “destination stripping” such that the packet only traverses a portion of the overall ring.
- In accordance with a preferred embodiment of the present invention, each node also includes a “port aliasing module” for receiving the learned MAC addresses and for recording in the forwarding table a port direction that is opposite to an actual port direction detected by the node. As the ring/broadcast domain is unidirectional, it logically is a single port but in actual implementation is an ingress and an egress. Normal Ethernet source learning will attempt to associate learned MAC addresses of traffic received from other ring nodes with the ingress port, while the desirable behaviour is to actually associate the forwarding for those MAC addresses to the egress port for the ring as the only viable path around the ring is unidirectional. Port aliasing permits the translation of learned information from ingress to egress prior to forwarding of traffic. This may be done prior to or subsequent to insertion of learned information into the local forwarding database. Precisely when the value is aliased is an implementation issue.
-
FIG. 1A is a schematic illustration of an Ethernet VLAN ring configured for 1:1 protection for Emulated LAN (ELAN) or Source Specific Broadcast (SSB) in accordance with an embodiment of the present invention. In this example, thering 10 has working and protection paths interconnecting four nodes A, B, C and D. In this example, traffic inserted at A is tagged with a Working VID (W-VID) corresponding to a configured working path routed A, B, C, D. There is also configured a protection VID (P-VID) configured in the reverse direction D, C, B, A with corresponding port membership for the VIDs being configured on the ring nodes. In this example, the VIDs are referenced with respect to Node A. Similar and co-routed (but different VIDS) would of course also be assigned for Nodes B, C and D. For Emulated LAN (ELAN), a total of two VIDs per virtual ring per ring node are required. For Source Specific Multicast (emulation of a p2mp, i.e. a point-to-multipoint, tree over the ring), a total of 4 VIDs per virtual ring are required. For Source Specific Broadcast (SSB), a total of two VIDs per virtual ring are required, in this case Working and Protection. In a simple variant, the VID can further identify which of the two directions around the ring the traffic is carried. Thus, in this particular variant, a West Working VID, West Protection VID, East Working VID and East Protection VID are defined for each node and, depending on which of the two directions is arbitrarily chosen for the working path, either the west VIDs or the east VIDs are used. -
FIG. 1B is an enlarged schematic illustration of Node A ofFIG. 1A operating in a fault-free state. In this example, Node A adds a ring tag to all the Ethernet frames (traffic) entering the ring. In this case, the ring tag added to the frames is W-VID because the traffic is being routed on the working path. As shown inFIG. 1B , Node A passes the P-VID and blocks the W-VID on the east port. -
FIG. 1C is an enlarged schematic illustration of Nodes B, C and D ofFIG. 1A operating in a fault-free state. In this example, Nodes B, C and D pass the P-VID (as did Node A) but these nodes pass the W-VID and takes a copy, removing the ring tag (VID) when the traffic is taken off the ring. - Accordingly, large (metro-sized), simple and inexpensive Ethernet rings can be implemented using 802.1Q-compliant hardware, i.e. using Q-tagging to form a resilient QinQ ring whose behaviour appears to be that of an 802.1Q-compliant bridge. Furthermore, as will be described below, these rings can be made resilient.
- Resiliency (1:1 Protection)
- The virtual Ethernet ring is made resilient (or “fault-tolerant”) by virtue of its ring topology (which is an inherently resilient topology because it is capable of ring folding to isolate a span failure), the presence of a protection path providing 1:1 protection, and the presence of cross-connects at each node that are capable of “hairpinning” the traffic when the ring folds, as is explained in the following paragraphs.
- Each node in the ring has its own cross-connect for cross-connecting the working path to the protection path. This enables ring folding in response to a failure detected in a span of the ring. Detecting a span failure can be done using any known span failure detection mechanism such as described in IEEE 802.1ag or 802.3ah EFM (“Ethernet First Mile”), which are hereby incorporated by reference. Folding the ring isolates the span failure and, due to the availability of the protection path, ensures that traffic continues to be forwarded seamlessly to destination nodes.
- As shown in
FIG. 2A , thering 10 can fold in response to aspan failure 16 by cross-connecting the workingpath 12 and theprotection path 14 at the two “end nodes” 18, 20 immediately on either side of the span failure. This will be referred to herein as “hairpinning” since the traffic takes what can be visualized as a “hairpin curve” (as shown inFIG. 2A ) as it is switched from the working path onto the protection path at thefirst end node 18, i.e. the last node that the traffic encounters on the working path just before the span failure. The traffic is then carried all the way back to thesecond end node 20 on the protection path (in the opposite direction) at which point this same traffic is then “hairpinned” again (i.e. cross-connected) back onto the working path. The failed span provides the “selector” synchronization mechanism for the protection switch. The net effect of the cross connecting at both ring nodes adjacent to the failure is that the protection path acts as a “bypass” to loop the traffic back to the working path while preserving the unidirectionality of the ring. Folding the ring using this double-hairpin arrangement not only preserves the unidirectionality of the working path but also ensures that traffic can only ingress or egress the ring from the working path. In other words, the working path always remains the working path even after a span fault. - As shown in
FIG. 2B , the first end node 18 (i.e. Node C in this example) cross-connects W-VID to P-VID (to thus effect a port egress translation). Similarly, as shown inFIG. 2C , the second end node 20 (i.e. Node D in this example) cross-connects P-VID to W-VID (to thus effect a port ingress translation). - A useful attribute of this arrangement is that protection switching is “hitless” with respect to MAC learning for ELAN and SSM. In other words, the ring folding preserves the topology with respect to learned MAC addresses.
- As another example,
FIGS. 3A-3C andFIGS. 4A-4C illustrate respectively the operation and folding of a virtual Ethernet ring configured for 1:1 protection to enable Source-Specific Multicast (SSM). In SSM, the configuration of connectivity is constrained such that only the source node (termed root)has connectivity to all other ring nodes (termed leaves), i.e. the other ring nodes can only communicate with the source. The SSM head-end only needs to know that a given ring node is interested, but does not need to know which one. Two working VIDs are required, one for the head-end to the leaves, and the other for the leaves to the head-end. Two protection VIDs are required, one for the working VID (root to leaf connectivity) and one for the working return VID (leaf to root connectivity). As shown in these figures, the workingpath 12 has aprotection path 14, and thereturn path 22 is protected by aprotection return 24. - Therefore, for a given SSM virtual ring, there are four paths, and four VIDs are defined for the ring. These VIDs can be designated as follows: Working (W-VID), Working Return (WR-VID), Protection (P-VID) and Protection Return (PR-VID).
- As shown in
FIG. 3B , Node A operates in a fault-free state by passing P-VID and PR-VID while blocking W-VID on the east port. Traffic entering the ring at Node A is tagged with W-VID and sent onto the ring via the west port of Node A (assuming, for this example, a westward working direction) while return traffic is taken off the ring on WR-VID. - As shown in
FIG. 3C , Nodes B, C and D operate in a fault-free state by also passing P-VID and PR-VID. At each of Nodes B, C and D, the node passes W-VID and takes a copy (stripping the VID as the traffic egresses the ring). Each of these nodes also passes WR-VID and inserts traffic onto W-VID by assigning a ring tag (W-VID). - As shown in
FIGS. 4A-4C , theEthernet ring 10 folds in response to afailure 16 in the span, e.g. between Nodes C and D. As shown inFIG. 4B , Node C (the first end node 18) cross-connects W-VID to P-VID and WR-VID to PR-VID (to thus effect a port egress translation). As shown inFIG. 4C , Node D (the second end node 20) cross-connects P-VID to W-VID (to thus effect a port ingress translation). - Accordingly, a highly resilient, unidirectional, virtual Ethernet ring can be created having one protection path per working path, thus providing 1:1 protection for either ELAN and SSB implementations or an SSM implementation.
- Resiliency (1+1 Protection)
- In another embodiment, as shown in
FIGS. 5A-5C , a 1+1 protection arrangement can be implemented by sending (“bi-casting”) traffic in opposite directions on both the working andprotection paths ring 10. In this 1+1 protection scenario, the ingress node not only sends the same traffic (i.e. the same frames) in opposite directions around the ring, but it also sends Connectivity Fault Management (CFM) heartbeats in both directions around the ring. The CFM heartbeats enable a destination node on the ring to select one of the two received copies of the bi-cast traffic based on the characteristics of the CFM heartbeats received at the destination node. - As shown in
FIG. 5B , Node A adds ring tags as traffic enters the ring as is bi-cast onto both the W-VID and P-VID. Node A also blocks P-VID and W-VID on the east port. As shown inFIG. 5C , each one of Nodes B, C and D has a selector that uses IEEE 802.1ag and G.8031 to select which of the two sets of bi-cast traffic it will treat as the working-path traffic. The VID is stripped when traffic exits the ring. Each node passes W-VID and takes a copy. Each node also passes P-VID and takes a copy. - VID Seizing
- At initialization of the ring, a range of VLANs is delegated to the operation of the ring, and the appropriate ring connectivity is configured via configuring of port membership for the VLAN set on each ring node. Each node may then self-discover and seize a set of unique ring tags (the subset of tags in the range delegated to the ring that will be used by the specific ring node). At each node, ring tags are randomly selected and tested. To test the ring tags, the node attempts to ping itself with a frame tagged with the selected working path ring tag. If the ring tag is not in use by any node in the ring, the node will be able to ping itself (i.e. there is uninterrupted connectivity around the ring). Otherwise, if the selected ring tag is already in use by another node in the ring, the node will not be able to ping itself because the actual owner of that selected working ring tag (i.e. another node) will have blocked the port for that ring tag in order to do source stripping.
- For a virtual Ethernet ring (e.g. ELAN), each node would need to seize two unique VIDS. VID discovery and seizing is done by randomly selecting a potentially usable VID associated with a specific ring at each node being initialized, sending the potentially usable VID around the ring to try to ping oneself and then seizing the VID if it returns unclaimed to the node that sent the VID. These steps are repeated until the node being initialized has pinged itself at least twice. The seizing is complete when a block of 2 VIDs are “owned” by the node being initialized.
- When the entire ring powers up at once, it is important to institute random delays in the self-discovery process to avoid “race conditions”. Thus, a given node should wait a random period of time before selecting a ring tag and attempting to ping itself.
- Moreover, to be safe, the node should ping itself a couple of times with the same ring tag to be certain that the VID is truly not in use and thus can legitimately be seized. When the node seizes a ring tag, it modifies the configuration for the seized range of ring tags from the default to the owned state.
- Node Implementation
-
FIG. 6 schematically illustrates, by way of example only, an Ethernet ring node (“Node X”) in accordance with an embodiment of the present invention. As shown inFIG. 6 , Node X has a routing switch 30 (e.g. Nortel 8608 or equivalent) and a switch fabric module 40 (e.g. Nortel 8692 or equivalent). Therouting switch 30 has aningress port 32 and anegress port 34 for traffic entering and exiting the ring. Therouting switch 34 includes a mapping module 36 (or other such means) for mapping a C-VID (Customer VID) received on the ingress port to a ring VID and pushing the frames to theswitch fabric module 40. Therouting switch 34 also includes a VID-stripping module 38 (or other such means) for stripping the ring VID from the traffic before it exits the ring via theegress port 34. - As further illustrated in
FIG. 6 , theswitch fabric module 40 includes forwardingmemory 42, a port,aliasing module 44, and a 802.lQ bridge 46. Thememory 42 maintains the forwarding table, e.g. the Forwarding Information Base, into which MAC addresses and port directions are stored. Theport aliasing module 44, as mentioned above, stores a port direction that is opposite to the actual learned direction. This port aliasing preserves the unidirectionality of the ring. Traffic is switched by the .1Q bridge 48 onto either theWest PHY 50 or theEast PHY 52. - Applications of the Virtual Ethernet Ring
- The ring is able to support a variety of Ethernet applications, including ELINE, E-TREE, Emulated LAN (ELAN), Source-Specific Multicast (SSM), and Source-Specific Broadcast (SSB). In the ELINE and E-TREE scenarios, the ring serves as a Provider Backbone Bridge (PBB) within a Provider Backbone Transport (PBT) network, which are described in U.S. Patent Application Publication 2005/0220096 entitled TRAFFIC ENGINEERING IN FRAME-BASED CARRIER NETWORKS published Oct. 6, 2005, which is hereby incorporated by reference. For ELINE and E-TREE, the PBT provides e2e PS (end-to-end protection switching) so the ring must not interfere with the PBT VID range. For ELAN, the ring operates as a resilient distributed switch. For SSM, the ring acts to resiliently fan out a dynamically varying set of (S,G) multicast groups to a set of ring nodes. For SSM, the ring must also provide a constrained return path for IGMP snooping/filtering. For SSB, the ring acts to resiliently fan out an invariant bundle of (S,G) multicast groups to a set of ring nodes, but unlike SSM, no return path is required. The virtual ring should be able to support all of these applications simultaneously.
- Node Configurations for Specific Implementations
- In order to simultaneously accommodate different applications or “behaviours”, e.g. ELAN, SSM and SSB, a range of VIDs is designated for each type of application or “behaviour”, i.e. a range of VIDs is designated for ELAN, another range of VIDs for SSM and yet another range of VIDs for SSB. The default is for each node to pre-configure each range and then, as required, seize specific VIDs in each range.
- For ELINE (such as Provider Backbone Transport, which offers its own end-to-end resiliency), a fixed network VID range is assigned.
- Emulated LAN (ELAN) can be enabled by specifying, in a generalized case, only two VIDs per ring node, namely a Working VID (W-VID) and a Protection VID (P-VID). In the specific case where the VIDs are to further identify ring direction, four VIDs are defined per ring node, e.g. a West Working VID, a West Protection VID, an East Working VID and an East Protection VID. Each node needs to both relay and take a copy of Working VIDs. Each node simply needs to connect Protection VIDs between ring ports. MAC learning is disabled on the Protection VIDs.
- Source Specific Multicast (SSM) can be enabled by specifying four VIDs per SSM ring (for the generalized case), i.e. a Working VID, Working Return VID, Protection VID and Protection Return VID. Each node needs to both relay and take a copy of Working VIDs. Each node needs to connect Protection and Working Return VIDs together. MAC learning is disabled on all VIDs.
- Source Specific Broadcast (SSB) can be enabled by specifying two VIDs per source node (W-VID and P-VID) per ring. Each node needs to both relay and take a copy of Working VIDS. Each node simply needs to connect Protection VIDs between ring ports. MAC learning is disabled on all VIDs.
- The embodiments of the invention described above are intended to be exemplary only. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.
Claims (18)
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/477,975 US20100238813A1 (en) | 2006-06-29 | 2006-06-29 | Q-in-Q Ethernet rings |
US11/955,888 US8085676B2 (en) | 2006-06-29 | 2007-12-13 | Method and system for looping back traffic in QIQ ethernet rings and 1:1 protected PBT trunks |
US14/251,999 US9319268B2 (en) | 2006-06-29 | 2014-04-14 | Q-in-Q Ethernet rings |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US11/477,975 US20100238813A1 (en) | 2006-06-29 | 2006-06-29 | Q-in-Q Ethernet rings |
Related Child Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/955,888 Continuation-In-Part US8085676B2 (en) | 2006-06-29 | 2007-12-13 | Method and system for looping back traffic in QIQ ethernet rings and 1:1 protected PBT trunks |
US14/251,999 Continuation US9319268B2 (en) | 2006-06-29 | 2014-04-14 | Q-in-Q Ethernet rings |
Publications (1)
Publication Number | Publication Date |
---|---|
US20100238813A1 true US20100238813A1 (en) | 2010-09-23 |
Family
ID=42737516
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US11/477,975 Abandoned US20100238813A1 (en) | 2006-06-29 | 2006-06-29 | Q-in-Q Ethernet rings |
US14/251,999 Expired - Fee Related US9319268B2 (en) | 2006-06-29 | 2014-04-14 | Q-in-Q Ethernet rings |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US14/251,999 Expired - Fee Related US9319268B2 (en) | 2006-06-29 | 2014-04-14 | Q-in-Q Ethernet rings |
Country Status (1)
Country | Link |
---|---|
US (2) | US20100238813A1 (en) |
Cited By (25)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20080144644A1 (en) * | 2006-12-14 | 2008-06-19 | Nortel Networks Limited | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas |
US20100039934A1 (en) * | 2006-10-31 | 2010-02-18 | Mcguire Alan | In-layer ethernet p-cycle protection scheme |
US20100195660A1 (en) * | 2009-02-05 | 2010-08-05 | Yamatake Corporation | Ring type ethernet system, ring type switch, ring connection control circuit, ring type ethernet system control method, ring type switch control method and ring connection control method |
US20100260188A1 (en) * | 2009-04-10 | 2010-10-14 | Dongchen Zhou | Method and device for processing qinq packet |
US20100278183A1 (en) * | 2008-01-25 | 2010-11-04 | Huawei Technologies Co., Ltd. | Method and Device for Sending a Packet Based on Tunneling Protocol Used in Layer 2 |
US20110019679A1 (en) * | 2009-07-23 | 2011-01-27 | Shinichi Akahane | Network relay apparatus |
US20110026394A1 (en) * | 2007-04-27 | 2011-02-03 | SUPCON GROUP CO., LTD. Zhejiang University | Distributed ethernet system and method for detecting fault based thereon |
US20120170487A1 (en) * | 2009-09-24 | 2012-07-05 | Zte Corporation | Method and system for preventing repeated updating of address table in ethernet ring network protection |
US8341717B1 (en) | 2008-11-13 | 2012-12-25 | Sprint Communications Company L.P. | Dynamic network policies based on device classification |
US20130003111A1 (en) * | 2011-06-30 | 2013-01-03 | Konica Minolta Laboratory U.S.A., Inc. | Method and system for network diagnostics which shows possible causes on a display of an image forming apparatus |
US8363658B1 (en) * | 2008-11-13 | 2013-01-29 | Sprint Communications Company L.P. | Dynamic firewall and dynamic host configuration protocol configuration |
US8479266B1 (en) | 2008-11-13 | 2013-07-02 | Sprint Communications Company L.P. | Network assignment appeal architecture and process |
US8509061B2 (en) | 2011-03-23 | 2013-08-13 | Ciena Corporation | Systems and methods for scaling performance of Ethernet ring protection protocol |
US20130272128A1 (en) * | 2012-04-16 | 2013-10-17 | Electronics And Telecommunications Research Institute | Method and apparatus of determining blocking in ring network |
CN103763201A (en) * | 2013-12-31 | 2014-04-30 | 深信服网络科技(深圳)有限公司 | Loop cutting-off method and device based on STP / RSTP protocol |
US20140310354A1 (en) * | 2011-06-15 | 2014-10-16 | Bae Systems Plc | Data transfer |
US20140313893A1 (en) * | 2011-12-16 | 2014-10-23 | Huawei Technologies Co., Ltd. | Method and Device for Processing Interconnected Ring in Multi-Protocol Label Switching |
US20150103673A1 (en) * | 2013-06-14 | 2015-04-16 | Fujitsu Telecom Networks Limited | Frame transmission apparatus and method for checking normality |
US20150103830A1 (en) * | 2012-03-05 | 2015-04-16 | Telefonaktiebolaget L M Ericsson (Publ) | The handling of data transfers in a network with a ring topology |
CN104579952A (en) * | 2013-10-25 | 2015-04-29 | 杭州华三通信技术有限公司 | Method and equipment for creating protecting tunnel for resisting multipoint faults of main tunnel |
US9197493B2 (en) | 2012-09-06 | 2015-11-24 | Ciena Corporation | Protection systems and methods for handling multiple faults and isolated nodes in interconnected ring networks |
CN107547336A (en) * | 2017-05-15 | 2018-01-05 | 新华三技术有限公司 | A kind of authentication port adds the method and device for authorizing VLAN |
US20180102969A1 (en) * | 2010-01-05 | 2018-04-12 | Futurewei Technologies, Inc. | Enhanced hierarchical virtual private local area network service (vpls) system and method for ethernet-tree (e-tree) services |
CN109714226A (en) * | 2018-12-21 | 2019-05-03 | 安徽皖通邮电股份有限公司 | A kind of detection protocol extended method based on MPLS L2VPN QINQ access service |
US10367654B2 (en) * | 2017-07-14 | 2019-07-30 | Fujitsu Limited | Network design method for ethernet ring protection switching |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111211957B (en) * | 2018-11-21 | 2021-10-01 | 华为技术有限公司 | Communication method and device |
US11444807B2 (en) | 2020-01-22 | 2022-09-13 | Ciena Corporation | EVPN VPWS FXC local switching connectivity |
US11171853B2 (en) | 2020-01-30 | 2021-11-09 | Ciena Corporation | Constraint-based event-driven telemetry |
US11658900B2 (en) | 2021-06-16 | 2023-05-23 | Ciena Corporation | Responding to operator commands in a multi-homing ethernet virtual private network (EVPN) |
US11950032B2 (en) | 2022-03-07 | 2024-04-02 | Ciena Corporation | G.8032 with optical bypass |
Citations (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5297137A (en) * | 1991-01-30 | 1994-03-22 | International Business Machines Corporation | Process for routing data packets around a multi-node communications network |
US5408610A (en) * | 1988-05-18 | 1995-04-18 | Canon Kabushiki Kaisha | Communication control apparatus which communicates management information in a communication system |
US5778003A (en) * | 1995-03-30 | 1998-07-07 | Newbridge Networks Corporation | Loop-back detection using out-of-band signalling |
US6272107B1 (en) * | 1998-05-12 | 2001-08-07 | 3Com Corporation | Method of path restoration in an ATM network utilizing point to point switched virtual circuits |
US6366556B1 (en) * | 1998-06-22 | 2002-04-02 | Lucent Technologies Inc. | Self-healing networks using virtual rings |
US20020176131A1 (en) * | 2001-02-28 | 2002-11-28 | Walters David H. | Protection switching for an optical network, and methods and apparatus therefor |
US6496516B1 (en) * | 1998-12-07 | 2002-12-17 | Pmc-Sierra, Ltd. | Ring interface and ring network bus flow control system |
US6532088B1 (en) * | 1999-09-10 | 2003-03-11 | Alcatel | System and method for packet level distributed routing in fiber optic rings |
US20030142678A1 (en) * | 2000-07-28 | 2003-07-31 | Chan Eric L. | Virtual path ring protection method and apparatus |
US6647428B1 (en) * | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
US20040004937A1 (en) * | 2002-07-05 | 2004-01-08 | Nortel Networks Limited | Method, device and software for establishing protection paths on demand and revertive protection switching in a communications network |
US6717909B2 (en) * | 2001-06-05 | 2004-04-06 | Marconi Communications, Inc. | Ethernet protection system providing fault tolerence for communication lines and interface cards according to classified failure states |
US6717922B2 (en) * | 2002-03-04 | 2004-04-06 | Foundry Networks, Inc. | Network configuration protocol and method for rapid traffic recovery and loop avoidance in ring topologies |
US6724781B1 (en) * | 1999-08-23 | 2004-04-20 | Marconi Communications, Inc. | System and method for packet transport in a ring network |
US6766482B1 (en) * | 2001-10-31 | 2004-07-20 | Extreme Networks | Ethernet automatic protection switching |
US20040179471A1 (en) * | 2001-03-07 | 2004-09-16 | Adisak Mekkittikul | Bi-directional flow-switched ring |
US6829347B1 (en) * | 2001-12-14 | 2004-12-07 | Nortel Networks Limited | Constraint based routing |
US6882620B1 (en) * | 1998-05-27 | 2005-04-19 | Emc Corporation | Token exchange system with fault protection |
US6892032B2 (en) * | 1997-08-27 | 2005-05-10 | Nortel Networks Limited | WDM optical network with passive pass-through at each node |
US6928050B2 (en) * | 2003-05-06 | 2005-08-09 | Overture Networks, Inc. | Protected switching ring |
US20050220096A1 (en) * | 2004-04-06 | 2005-10-06 | Robert Friskney | Traffic engineering in frame-based carrier networks |
US20060039371A1 (en) * | 2004-08-19 | 2006-02-23 | Microsoft Corporation | Network routing |
US20060062141A1 (en) * | 2001-06-14 | 2006-03-23 | Cisco Technology, Inc. | Method and apparatus for fast failure detection in switched LAN networks |
US7035259B2 (en) * | 2000-03-06 | 2006-04-25 | Fujitsu Limited | Label switch network system |
US7043250B1 (en) * | 2003-04-16 | 2006-05-09 | Verizon Corporate Services Group Inc. | Systems and methods for forming and operating a communications network |
US20060109802A1 (en) * | 2004-11-19 | 2006-05-25 | Corrigent Systems Ltd. | Virtual private LAN service over ring networks |
US7065040B2 (en) * | 2001-09-21 | 2006-06-20 | Fujitsu Limited | Ring switching method and node apparatus using the same |
US7096275B1 (en) * | 2000-06-06 | 2006-08-22 | Lucent Technologies Inc. | Methods and apparatus for protection against network failures |
US7133358B2 (en) * | 2001-05-17 | 2006-11-07 | Fujitsu Limited | Failure control unit |
US7142504B1 (en) * | 2001-04-25 | 2006-11-28 | Cisco Technology, Inc. | Fault tolerant network traffic management |
US7145882B2 (en) * | 2002-04-04 | 2006-12-05 | Bay Microsystems, Inc. | Multiplexed automatic protection switching channels |
US7167441B2 (en) * | 2001-12-22 | 2007-01-23 | 3Com Corporation | Cascade control system for network units |
US20070047471A1 (en) * | 2005-08-30 | 2007-03-01 | Lionel Florit | System and method for implementing virtual ports within ring networks |
US7203748B2 (en) * | 2002-02-15 | 2007-04-10 | International Business Machines Corporation | Method for detecting the quick restart of liveness daemons in a distributed multinode data processing system |
US7209975B1 (en) * | 2002-03-15 | 2007-04-24 | Sprint Communications Company L.P. | Area based sub-path protection for communication networks |
US20070121635A1 (en) * | 2004-06-08 | 2007-05-31 | Yang Zhou | Method of implementing association in Automatic Switched Optical Network (ASON) |
US20070220175A1 (en) * | 2006-03-17 | 2007-09-20 | Sanjay Khanna | Method and apparatus for media distribution using VPLS in a ring topology |
US7280470B2 (en) * | 1997-11-28 | 2007-10-09 | Nec Corporation | Ring network for sharing protection resource by working communication paths |
US20070280251A1 (en) * | 2004-09-27 | 2007-12-06 | Huawei Technologies Co., Ltd. | Ring Network And A Method For Implementing The Service Thereof |
US7324440B2 (en) * | 2002-02-06 | 2008-01-29 | Nec Corporation | Multiring control method, node using the method, and control program |
US7385917B1 (en) * | 2000-05-05 | 2008-06-10 | Fujitsu Limited | Method and system for providing a protection path for connectionless signals in a telecommunications network |
US7406032B2 (en) * | 2005-01-06 | 2008-07-29 | At&T Corporation | Bandwidth management for MPLS fast rerouting |
US7447429B2 (en) * | 2003-03-14 | 2008-11-04 | Fujitsu Limited | Bidirectional line switched ring network |
US20080304407A1 (en) * | 2004-09-16 | 2008-12-11 | Alcatel Telecom Israel | Efficient Protection Mechanisms For Protecting Multicast Traffic in a Ring Topology Network Utilizing Label Switching Protocols |
US20090040922A1 (en) * | 2004-05-06 | 2009-02-12 | Umansky Igor | Efficient protection mechanisms in a ring topology network utilizing label switching protocols |
US7532588B2 (en) * | 2003-02-19 | 2009-05-12 | Nec Corporation | Network system, spanning tree configuration method and configuration program, and spanning tree configuration node |
US7623446B1 (en) * | 2005-11-14 | 2009-11-24 | Nortel Networks Limited | MPLS virtual rings |
US7639709B1 (en) * | 2006-01-20 | 2009-12-29 | Rockwell Collins, Inc. | System and method for broadcast conflict resolution |
US7643407B2 (en) * | 2004-01-29 | 2010-01-05 | Nortel Networks Limited | Method and apparatus for determining protection transmission unit allocation |
US7701848B2 (en) * | 2003-07-11 | 2010-04-20 | Chunming Qiao | Efficient trap avoidance and shared protection method in survivable networks with shared risk link groups and a survivable network |
US7796504B1 (en) * | 1999-10-21 | 2010-09-14 | Tellabs Operations, Inc. | Method for establishing an MPLS data network protection pathway |
US7835267B2 (en) * | 2005-05-09 | 2010-11-16 | Cisco Technology, Inc. | Dynamic path protection in an optical network |
US7965938B2 (en) * | 2004-09-10 | 2011-06-21 | Huawei Technologies Co., Ltd. | Method for mesh optical network service restoration |
EP2365668A2 (en) * | 2003-04-29 | 2011-09-14 | Alcatel Lucent | Protection scheme for a communications network under multiple failures |
US8050183B2 (en) * | 2005-05-06 | 2011-11-01 | Cisco Technology, Inc. | System and method for implementing reflector ports within hierarchical networks |
Family Cites Families (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS6022849A (en) | 1984-06-01 | 1985-02-05 | Hitachi Ltd | Method for setting automatically address in transmission system |
JP2000196642A (en) | 1998-12-28 | 2000-07-14 | Canon Inc | Node device, network using the same and its transmission controlling method |
US6791939B1 (en) | 1999-06-02 | 2004-09-14 | Sun Microsystems, Inc. | Dynamic generation of deadlock-free routings |
GB2357390B (en) | 1999-12-16 | 2002-09-25 | 3Com Corp | Ethernet units adapted for loop configuration and method of operating same |
JP4215369B2 (en) | 2000-02-09 | 2009-01-28 | 株式会社日立コミュニケーションテクノロジー | Network transmission apparatus and network transmission system |
IL151796A0 (en) * | 2002-09-18 | 2003-04-10 | Lightscape Networks Ltd | Method for protection of ethernet traffic in optical ring networks |
CN100388700C (en) * | 2002-10-18 | 2008-05-14 | 华为技术有限公司 | Method for transmitting digital business on synchronous digital network |
JP4108524B2 (en) | 2003-04-14 | 2008-06-25 | 日本電気株式会社 | ATM bridge device and loop detection method in ATM bridge |
CN100344116C (en) | 2004-04-20 | 2007-10-17 | 北京润光泰力科技发展有限公司 | A method and apparatus for Ethernet converter line side loop back detection |
JP4358232B2 (en) | 2004-07-30 | 2009-11-04 | 三菱電機株式会社 | Communication system, packet switch device, and edge node device |
CN100389577C (en) * | 2005-05-30 | 2008-05-21 | 华为技术有限公司 | Method and equipment for implementing broadcast or multicast on elastic packet ring |
-
2006
- 2006-06-29 US US11/477,975 patent/US20100238813A1/en not_active Abandoned
-
2014
- 2014-04-14 US US14/251,999 patent/US9319268B2/en not_active Expired - Fee Related
Patent Citations (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5408610A (en) * | 1988-05-18 | 1995-04-18 | Canon Kabushiki Kaisha | Communication control apparatus which communicates management information in a communication system |
US5297137A (en) * | 1991-01-30 | 1994-03-22 | International Business Machines Corporation | Process for routing data packets around a multi-node communications network |
US5778003A (en) * | 1995-03-30 | 1998-07-07 | Newbridge Networks Corporation | Loop-back detection using out-of-band signalling |
US6892032B2 (en) * | 1997-08-27 | 2005-05-10 | Nortel Networks Limited | WDM optical network with passive pass-through at each node |
US7280470B2 (en) * | 1997-11-28 | 2007-10-09 | Nec Corporation | Ring network for sharing protection resource by working communication paths |
US6272107B1 (en) * | 1998-05-12 | 2001-08-07 | 3Com Corporation | Method of path restoration in an ATM network utilizing point to point switched virtual circuits |
US6882620B1 (en) * | 1998-05-27 | 2005-04-19 | Emc Corporation | Token exchange system with fault protection |
US6366556B1 (en) * | 1998-06-22 | 2002-04-02 | Lucent Technologies Inc. | Self-healing networks using virtual rings |
US6496516B1 (en) * | 1998-12-07 | 2002-12-17 | Pmc-Sierra, Ltd. | Ring interface and ring network bus flow control system |
US6724781B1 (en) * | 1999-08-23 | 2004-04-20 | Marconi Communications, Inc. | System and method for packet transport in a ring network |
US6532088B1 (en) * | 1999-09-10 | 2003-03-11 | Alcatel | System and method for packet level distributed routing in fiber optic rings |
US7796504B1 (en) * | 1999-10-21 | 2010-09-14 | Tellabs Operations, Inc. | Method for establishing an MPLS data network protection pathway |
US7035259B2 (en) * | 2000-03-06 | 2006-04-25 | Fujitsu Limited | Label switch network system |
US6647428B1 (en) * | 2000-05-05 | 2003-11-11 | Luminous Networks, Inc. | Architecture for transport of multiple services in connectionless packet-based communication networks |
US7385917B1 (en) * | 2000-05-05 | 2008-06-10 | Fujitsu Limited | Method and system for providing a protection path for connectionless signals in a telecommunications network |
US7096275B1 (en) * | 2000-06-06 | 2006-08-22 | Lucent Technologies Inc. | Methods and apparatus for protection against network failures |
US20030142678A1 (en) * | 2000-07-28 | 2003-07-31 | Chan Eric L. | Virtual path ring protection method and apparatus |
US20020176131A1 (en) * | 2001-02-28 | 2002-11-28 | Walters David H. | Protection switching for an optical network, and methods and apparatus therefor |
US20040179471A1 (en) * | 2001-03-07 | 2004-09-16 | Adisak Mekkittikul | Bi-directional flow-switched ring |
US7142504B1 (en) * | 2001-04-25 | 2006-11-28 | Cisco Technology, Inc. | Fault tolerant network traffic management |
US7133358B2 (en) * | 2001-05-17 | 2006-11-07 | Fujitsu Limited | Failure control unit |
US6717909B2 (en) * | 2001-06-05 | 2004-04-06 | Marconi Communications, Inc. | Ethernet protection system providing fault tolerence for communication lines and interface cards according to classified failure states |
US20060062141A1 (en) * | 2001-06-14 | 2006-03-23 | Cisco Technology, Inc. | Method and apparatus for fast failure detection in switched LAN networks |
US7065040B2 (en) * | 2001-09-21 | 2006-06-20 | Fujitsu Limited | Ring switching method and node apparatus using the same |
US6766482B1 (en) * | 2001-10-31 | 2004-07-20 | Extreme Networks | Ethernet automatic protection switching |
US6829347B1 (en) * | 2001-12-14 | 2004-12-07 | Nortel Networks Limited | Constraint based routing |
US7167441B2 (en) * | 2001-12-22 | 2007-01-23 | 3Com Corporation | Cascade control system for network units |
US7324440B2 (en) * | 2002-02-06 | 2008-01-29 | Nec Corporation | Multiring control method, node using the method, and control program |
US7203748B2 (en) * | 2002-02-15 | 2007-04-10 | International Business Machines Corporation | Method for detecting the quick restart of liveness daemons in a distributed multinode data processing system |
US6717922B2 (en) * | 2002-03-04 | 2004-04-06 | Foundry Networks, Inc. | Network configuration protocol and method for rapid traffic recovery and loop avoidance in ring topologies |
US7209975B1 (en) * | 2002-03-15 | 2007-04-24 | Sprint Communications Company L.P. | Area based sub-path protection for communication networks |
US7145882B2 (en) * | 2002-04-04 | 2006-12-05 | Bay Microsystems, Inc. | Multiplexed automatic protection switching channels |
US20040004937A1 (en) * | 2002-07-05 | 2004-01-08 | Nortel Networks Limited | Method, device and software for establishing protection paths on demand and revertive protection switching in a communications network |
US7532588B2 (en) * | 2003-02-19 | 2009-05-12 | Nec Corporation | Network system, spanning tree configuration method and configuration program, and spanning tree configuration node |
US7447429B2 (en) * | 2003-03-14 | 2008-11-04 | Fujitsu Limited | Bidirectional line switched ring network |
US7043250B1 (en) * | 2003-04-16 | 2006-05-09 | Verizon Corporate Services Group Inc. | Systems and methods for forming and operating a communications network |
EP2365668A2 (en) * | 2003-04-29 | 2011-09-14 | Alcatel Lucent | Protection scheme for a communications network under multiple failures |
US6928050B2 (en) * | 2003-05-06 | 2005-08-09 | Overture Networks, Inc. | Protected switching ring |
US7701848B2 (en) * | 2003-07-11 | 2010-04-20 | Chunming Qiao | Efficient trap avoidance and shared protection method in survivable networks with shared risk link groups and a survivable network |
US7643407B2 (en) * | 2004-01-29 | 2010-01-05 | Nortel Networks Limited | Method and apparatus for determining protection transmission unit allocation |
US20050220096A1 (en) * | 2004-04-06 | 2005-10-06 | Robert Friskney | Traffic engineering in frame-based carrier networks |
US20090040922A1 (en) * | 2004-05-06 | 2009-02-12 | Umansky Igor | Efficient protection mechanisms in a ring topology network utilizing label switching protocols |
US20070121635A1 (en) * | 2004-06-08 | 2007-05-31 | Yang Zhou | Method of implementing association in Automatic Switched Optical Network (ASON) |
US20060039371A1 (en) * | 2004-08-19 | 2006-02-23 | Microsoft Corporation | Network routing |
US7965938B2 (en) * | 2004-09-10 | 2011-06-21 | Huawei Technologies Co., Ltd. | Method for mesh optical network service restoration |
US20080304407A1 (en) * | 2004-09-16 | 2008-12-11 | Alcatel Telecom Israel | Efficient Protection Mechanisms For Protecting Multicast Traffic in a Ring Topology Network Utilizing Label Switching Protocols |
US20070280251A1 (en) * | 2004-09-27 | 2007-12-06 | Huawei Technologies Co., Ltd. | Ring Network And A Method For Implementing The Service Thereof |
US20060109802A1 (en) * | 2004-11-19 | 2006-05-25 | Corrigent Systems Ltd. | Virtual private LAN service over ring networks |
US7406032B2 (en) * | 2005-01-06 | 2008-07-29 | At&T Corporation | Bandwidth management for MPLS fast rerouting |
US8050183B2 (en) * | 2005-05-06 | 2011-11-01 | Cisco Technology, Inc. | System and method for implementing reflector ports within hierarchical networks |
US7835267B2 (en) * | 2005-05-09 | 2010-11-16 | Cisco Technology, Inc. | Dynamic path protection in an optical network |
US20070047471A1 (en) * | 2005-08-30 | 2007-03-01 | Lionel Florit | System and method for implementing virtual ports within ring networks |
US7623446B1 (en) * | 2005-11-14 | 2009-11-24 | Nortel Networks Limited | MPLS virtual rings |
US7639709B1 (en) * | 2006-01-20 | 2009-12-29 | Rockwell Collins, Inc. | System and method for broadcast conflict resolution |
US20070220175A1 (en) * | 2006-03-17 | 2007-09-20 | Sanjay Khanna | Method and apparatus for media distribution using VPLS in a ring topology |
Cited By (41)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20100039934A1 (en) * | 2006-10-31 | 2010-02-18 | Mcguire Alan | In-layer ethernet p-cycle protection scheme |
US8111613B2 (en) * | 2006-10-31 | 2012-02-07 | British Telecommunications Public Limited Company | In-layer ethernet p-cycle protection scheme |
US8879424B2 (en) * | 2006-12-14 | 2014-11-04 | Constellation Technologies Llc | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas |
US20120263075A1 (en) * | 2006-12-14 | 2012-10-18 | David Allan | Method and Apparatus for Exchanging Routing Information and the Establishment of Connectivity Across Multiple Network Areas |
US20080144644A1 (en) * | 2006-12-14 | 2008-06-19 | Nortel Networks Limited | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas |
US8223668B2 (en) * | 2006-12-14 | 2012-07-17 | Rockstar Bidco Lp | Method and apparatus for exchanging routing information and the establishment of connectivity across multiple network areas |
US8339969B2 (en) * | 2007-04-27 | 2012-12-25 | Supcon Group Co., Ltd. | Distributed ethernet system and method for detecting fault based thereon |
US20110026394A1 (en) * | 2007-04-27 | 2011-02-03 | SUPCON GROUP CO., LTD. Zhejiang University | Distributed ethernet system and method for detecting fault based thereon |
US20100278183A1 (en) * | 2008-01-25 | 2010-11-04 | Huawei Technologies Co., Ltd. | Method and Device for Sending a Packet Based on Tunneling Protocol Used in Layer 2 |
US8509243B2 (en) * | 2008-01-25 | 2013-08-13 | Huawei Technologies Co., Ltd. | Method and device for sending a packet based on tunneling protocol used in layer 2 |
US8341717B1 (en) | 2008-11-13 | 2012-12-25 | Sprint Communications Company L.P. | Dynamic network policies based on device classification |
US8752160B1 (en) * | 2008-11-13 | 2014-06-10 | Sprint Communications Company L.P. | Dynamic firewall and dynamic host configuration protocol configuration |
US8363658B1 (en) * | 2008-11-13 | 2013-01-29 | Sprint Communications Company L.P. | Dynamic firewall and dynamic host configuration protocol configuration |
US8479266B1 (en) | 2008-11-13 | 2013-07-02 | Sprint Communications Company L.P. | Network assignment appeal architecture and process |
US8320387B2 (en) * | 2009-02-05 | 2012-11-27 | Azbil Corporation | Ring type ethernet system, ring type switch, ring connection control circuit, ring type ethernet system control method, ring type switch control method and ring connection control method |
US20100195660A1 (en) * | 2009-02-05 | 2010-08-05 | Yamatake Corporation | Ring type ethernet system, ring type switch, ring connection control circuit, ring type ethernet system control method, ring type switch control method and ring connection control method |
US20100260188A1 (en) * | 2009-04-10 | 2010-10-14 | Dongchen Zhou | Method and device for processing qinq packet |
US20110019679A1 (en) * | 2009-07-23 | 2011-01-27 | Shinichi Akahane | Network relay apparatus |
US8483051B2 (en) * | 2009-07-23 | 2013-07-09 | Alaxala Networks Corporation | Network relay apparatus |
US8693370B2 (en) * | 2009-09-24 | 2014-04-08 | Zte Corporation | Method and system for preventing repeated updating of address table in ethernet ring network protection |
US20120170487A1 (en) * | 2009-09-24 | 2012-07-05 | Zte Corporation | Method and system for preventing repeated updating of address table in ethernet ring network protection |
US11528223B2 (en) * | 2010-01-05 | 2022-12-13 | Huawei Technologies Co., Ltd. | Enhanced hierarchical virtual private local area network service (VPLS) system and method for Ethernet-Tree (E-Tree) services |
US20180102969A1 (en) * | 2010-01-05 | 2018-04-12 | Futurewei Technologies, Inc. | Enhanced hierarchical virtual private local area network service (vpls) system and method for ethernet-tree (e-tree) services |
US8509061B2 (en) | 2011-03-23 | 2013-08-13 | Ciena Corporation | Systems and methods for scaling performance of Ethernet ring protection protocol |
US20140310354A1 (en) * | 2011-06-15 | 2014-10-16 | Bae Systems Plc | Data transfer |
US10404792B2 (en) * | 2011-06-15 | 2019-09-03 | Bae Systems Plc | Data transfer |
US20130003111A1 (en) * | 2011-06-30 | 2013-01-03 | Konica Minolta Laboratory U.S.A., Inc. | Method and system for network diagnostics which shows possible causes on a display of an image forming apparatus |
US9515923B2 (en) * | 2011-12-16 | 2016-12-06 | Huawei Technologies Co., Ltd. | Method and device for processing interconnected ring in multi-protocol label switching |
US20140313893A1 (en) * | 2011-12-16 | 2014-10-23 | Huawei Technologies Co., Ltd. | Method and Device for Processing Interconnected Ring in Multi-Protocol Label Switching |
US20150103830A1 (en) * | 2012-03-05 | 2015-04-16 | Telefonaktiebolaget L M Ericsson (Publ) | The handling of data transfers in a network with a ring topology |
US9716652B2 (en) * | 2012-03-05 | 2017-07-25 | Telefonaktiebolaget L M Ericsson (Publ) | Handling of data transfers in a network with a ring topology |
US20130272128A1 (en) * | 2012-04-16 | 2013-10-17 | Electronics And Telecommunications Research Institute | Method and apparatus of determining blocking in ring network |
US9124502B2 (en) * | 2012-04-16 | 2015-09-01 | Electronics And Telecommunications Research Institute | Method and apparatus of determining blocking in ring network |
US9197493B2 (en) | 2012-09-06 | 2015-11-24 | Ciena Corporation | Protection systems and methods for handling multiple faults and isolated nodes in interconnected ring networks |
US9565064B2 (en) * | 2013-06-14 | 2017-02-07 | Fujitsu Limited | Frame transmission apparatus and method for checking normality |
US20150103673A1 (en) * | 2013-06-14 | 2015-04-16 | Fujitsu Telecom Networks Limited | Frame transmission apparatus and method for checking normality |
CN104579952A (en) * | 2013-10-25 | 2015-04-29 | 杭州华三通信技术有限公司 | Method and equipment for creating protecting tunnel for resisting multipoint faults of main tunnel |
CN103763201A (en) * | 2013-12-31 | 2014-04-30 | 深信服网络科技(深圳)有限公司 | Loop cutting-off method and device based on STP / RSTP protocol |
CN107547336A (en) * | 2017-05-15 | 2018-01-05 | 新华三技术有限公司 | A kind of authentication port adds the method and device for authorizing VLAN |
US10367654B2 (en) * | 2017-07-14 | 2019-07-30 | Fujitsu Limited | Network design method for ethernet ring protection switching |
CN109714226A (en) * | 2018-12-21 | 2019-05-03 | 安徽皖通邮电股份有限公司 | A kind of detection protocol extended method based on MPLS L2VPN QINQ access service |
Also Published As
Publication number | Publication date |
---|---|
US9319268B2 (en) | 2016-04-19 |
US20140226463A1 (en) | 2014-08-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9319268B2 (en) | Q-in-Q Ethernet rings | |
US8085676B2 (en) | Method and system for looping back traffic in QIQ ethernet rings and 1:1 protected PBT trunks | |
CN101364926B (en) | Method and apparatus for network protection | |
US7593400B2 (en) | MAC address learning in a distributed bridge | |
US8565069B2 (en) | Method of shrinking a data loss window in a packet network device | |
US9197493B2 (en) | Protection systems and methods for handling multiple faults and isolated nodes in interconnected ring networks | |
US9473382B2 (en) | Method and system for link aggregation | |
US9491041B2 (en) | Ethernet chain protection switching | |
US20090323518A1 (en) | Ring rapid spanning tree protocol | |
US20060029071A1 (en) | Multiplexing system that supports a geographically distributed subnet | |
US20110194404A1 (en) | System and method for fast protection of dual-homed virtual private lan service (vpls) spokes | |
US20120170449A1 (en) | Technique for protecting communication traffic in a connection having redundancy | |
JPWO2004075485A1 (en) | Network system, spanning tree configuration method and configuration program, spanning tree configuration node | |
US8787147B2 (en) | Ten gigabit Ethernet port protection systems and methods | |
CN111935013B (en) | Flow forwarding control method and device, flow forwarding method and chip, and switch | |
US20170063617A1 (en) | Seamless migration from rapid spanning tree protocol to ethernet ring protection switching protocol | |
Weibel | Tutorial on parallel redundancy protocol (PRP) | |
Huynh et al. | RRR: Rapid ring recovery submillisecond decentralized recovery for ethernet ring | |
CN104092574B (en) | A kind of IRF divisions cause the treating method and apparatus of RPR ring failures | |
Jin et al. | Ethernet ultra-fast switching: a tree-based local recovery scheme | |
James | A scalable architecture for high availability seamless redundancy (HSR) | |
Veisllari et al. | Employing ethernet spanning tree protocols in an integrated hybrid optical network | |
Santos et al. | Improving carrier ethernet recovery time using a fast reroute mechanism | |
James | Applying ADM and OpenFlow to Build High Availability Networks | |
Su et al. | Ethernet Ultra Fast Switching: A tree-based local recovery scheme |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: NORTEL NETWORKS LIMITED, CANADA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ALLAN, DAVID;BRAGG, NIGEL;HOLNESS, MARC;SIGNING DATES FROM 20060623 TO 20060629;REEL/FRAME:018070/0400 |
|
AS | Assignment |
Owner name: ROCKSTAR BIDCO, LP, NEW YORK Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:NORTEL NETWORKS LIMITED;REEL/FRAME:027143/0717 Effective date: 20110729 |
|
AS | Assignment |
Owner name: ROCKSTAR CONSORTIUM US LP, TEXAS Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROCKSTAR BIDCO, LP;REEL/FRAME:032436/0804 Effective date: 20120509 |
|
AS | Assignment |
Owner name: RPX CLEARINGHOUSE LLC, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ROCKSTAR CONSORTIUM US LP;ROCKSTAR CONSORTIUM LLC;BOCKSTAR TECHNOLOGIES LLC;AND OTHERS;REEL/FRAME:034924/0779 Effective date: 20150128 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: JPMORGAN CHASE BANK, N.A., AS COLLATERAL AGENT, IL Free format text: SECURITY AGREEMENT;ASSIGNORS:RPX CORPORATION;RPX CLEARINGHOUSE LLC;REEL/FRAME:038041/0001 Effective date: 20160226 |
|
AS | Assignment |
Owner name: RPX CLEARINGHOUSE LLC, CALIFORNIA Free format text: RELEASE (REEL 038041 / FRAME 0001);ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:044970/0030 Effective date: 20171222 Owner name: RPX CORPORATION, CALIFORNIA Free format text: RELEASE (REEL 038041 / FRAME 0001);ASSIGNOR:JPMORGAN CHASE BANK, N.A.;REEL/FRAME:044970/0030 Effective date: 20171222 |