A switch may be logically partitioned into a number of virtual switches, each functioning as an independent switch. Such partitioning of a physical switch may be done for the purpose of segregating traffic, much like a partitioned server where one physical server runs multiple virtual machines. For example, virtual switches may be created within physical switches of a ring network to separate different client networks that may be connected to the physical switches; however, each virtual switch requires its own link to another node on the ring network. Therefore, any advantages of the multiple virtual switches on the ring are either lost due to the virtual switches requiring multiple physical links for forming rings, or due to the virtual switches having to wait for access to a single ring.
According to one example embodiment of the present invention, a ring network may have multiple physical switches configured with multiple virtual switches with access to a common path on the ring network. The multiple virtual switches may include modules that add multicast information to traffic to direct the traffic along the common path to at least one other physical switch on the ring network.
In another example embodiment, a physical switch configured with multiple virtual switches may include at least one module to add multicast information to traffic to cause at least two of the multiple virtual switches to direct the traffic to a common path to at least one other physical switch, and may include at least one module to inspect multicast information in traffic received from a path from other virtual switches in another physical switch to direct the traffic to a destination associated with at least one of the multiple virtual switches.
In yet another example embodiment, a traffic signal may be embodied in a carrier wave supporting communications in a ring network, and may include overhead bits with multicast information and at least one bit defining the traffic to be “flood” traffic.
The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention.
A description of example embodiments of the invention follows.
Resilient Packet Ring (RPR) in noun form refers to a ring-based network protocol that supports bridging to other network protocols, such as Ethernet. Today's RPR uses 48-bit source and destination Media Access Control (MAC) addresses in the same format as Ethernet. When an Ethernet frame is bridged onto an RPR ring, an RPR station on the ring encapsulates the Ethernet frame with an RPR header in an RPR frame. Likewise, when a station copies an RPR frame from the ring, the station removes the RPR header from the RPR frame in the Ethernet traffic.
To transmit a frame from one RPR station to another on the RPR ring, RPR processing in the RPR station encapsulates the frame with an RPR header and adds the newly formed RPR frame to the ring. A station may flood the RPR frame to all other stations on the ring by setting information in the RPR header to indicate that the frame is to be flooded. While the RPR frame traverses the ring, it encounters other RPR stations.
At a given station, the destination MAC address of the RPR header is examined. If the destination address of the frame's RPR header is the same as the station's address and the frame is not indicated as being flooded, then the frame is copied without being forwarded to the next station on the ring. On the other hand, if the destination address of the RPR header is different than the station's address and the frame is not indicated as being flooded, then the frame is forwarded to the next station on the ring. However, if the frame is indicated as being flooded, then the frame is copied before being forwarded to the next station on the ring. To prevent a flooded frame from endlessly traveling around the ring, the station will also examine the source address of the RPR header. If the source address is the same as the station's address, then the frame will be dropped, thus, preventing an infinite loop.
When an RPR station receives a non-flooded RPR frame and recognizes the destination address, it removes the RPR frame completely from the ring, unlike in the case of flooded frames, that simply copy the contents of the frame and let the frame traverse the rest of the ring. When the receiving station removes the RPR frame from the ring, the bandwidth otherwise consumed by the RPR frame is available for use by other RPR stations. This is known as spatial reuse. It should be noted that an RPR station may implement spatial reuse if the destination of the frame is one of the RPR stations, otherwise, the station must flood the frame on the ring.
Current RPR technology allows each RPR physical port to be associated with only one virtual switch instance within a physical switch, which limits the number of subscribers that can access an RPR ring if virtual switches are used to separate subscribers.
Today's Virtual Local Area Networks (VLAN) allow multiple subscribers to access an RPR ring, but do not allow multiple virtual switches to access an RPR ring. Moreover, a limited number (e.g., 4096) of VLANs can be supported on a ring due to space limitations of VLAN identifiers in header information of traffic packets if an RPR physical port can be associated with only one virtual switch within a physical switch.
Unicast tunnels over an RPR ring can be used to allow multiple virtual switches to share an RPR ring with spatial reuse, but the approach requires Label Switched Path (LSP) configuration. Moreover, it does not support multicast traffic.
The use of an RPR ring over Virtual Concatenation (VCAT) allows for the use of multiple RPR rings, as the bandwidth in VCAT is divided into smaller circuits that act as independent circuits, but the bandwidth for each ring is fixed. This approach is inadequate as the provisioning and implementation of RPR rings over VCAT is overly complicated and wastes bandwidth.
The present method and apparatus allows multiple virtual switches in a physical switch to share one physical Resilient Packet Ring (RPR) without using LSP provisioning. According to an example present method, an RPR ring is partitioned into a set of logical entities to allow multiple virtual switching instances within a physical switch to access the physical RPR ring over a wavelength. These logical entities may be envisioned as virtual RPR subrings. Each virtual RPR subring behaves the same as an RPR ring as defined by IEEE 802.17, and can support many (e.g., 4096) Virtual LANs (VLANs). The entire ring, therefore, may support as many (e.g., 4096)×N VLANs, where N is the number of virtual RPR subrings. The virtual RPR subrings have flexible bandwidth allocation and may co-exist with unicast LSP tunnels, or Layer 2 bridging traffic over the RPR ring.
In one method for providing such virtual RPR subrings, multicast information is added by a virtual switch to traffic to be communicated between a group of virtual switches in different physical switches on a ring network. The traffic is then forwarded to a path between the different physical switches on the ring network already carrying other traffic between other virtual switches that are also in the different physical switches. It should be noted that the path between the different physical switches may carry traffic from all of the virtual switches on the ring network, and that a virtual RPR subring is part of the path, connecting virtual switches belonging to the same group. Only traffic traveling between the virtual switches in the group may travel over the virtual RPR subring. Traffic traveling between different virtual switches belonging to different groups travel over different virtual RPR subrings.
Upon receiving traffic at a given physical switch from an RPR subring, the traffic is provided to multiple virtual switches within the physical switch. The traffic is then forwarded to a destination associated with at least one of the virtual switches if the traffic includes virtual switch information corresponding to a virtual switch identifier of the virtual switch.
The multicast information in the traffic may include a virtual ring label to identify a virtual ring connecting virtual switches belonging to the same group and a tunnel label to instruct the RPR station to flood the frame (e.g., setting a flood indication to “true”). The virtual ring label may include virtual switch information corresponding to a virtual switch identifier shared by at least two virtual switches in different physical switches. It should be noted that all virtual switches belonging to the same group have the same virtual switch identifier, which may act as the identifier of the virtual ring that connects the virtual switches of the group.
In the illustrated ring network 200, a given virtual subring 230r1-1,2,3, 230r2-1,2,3 carries traffic 215r1, 215r2 between virtual switches within the same group but at different locations on the ring network. For example, traffic 215r1, 215r2 coming into virtual switch A1220a-1 on physical switch A 205a is sent to virtual switches B1220b-1, C1220c-1, and D1220d-1 in physical switches B 205b, C 205c, and D 205d, respectively, via subring 230r1-1. This is the case because virtual switches A1220a-1, B1220b-1, C1220c-1, and D1220d-1 share the same virtual switch identifier and, therefore, share the same virtual subring 230r1-1. Likewise, virtual switches A2220a-2, B2220b-2, C2220c-2, and D2220d-2 share virtual subring 230r1-2, and virtual switches A3220a-3, B3220b-3, C3220c-3, and D3220d-3 share virtual subring 230r1-3.
The virtual subrings 230r1-1,2,3, 230r2-1,2,3 are separated using virtual ring identifiers, and traffic packets traveling over the virtual subrings are transmitted through a multicast tunnel (not shown). For each virtual subring, a tunnel label is used to designate the traffic as being multicast traffic, and a virtual ring label is used to indicate that the multicast traffic is to be shared by virtual switches with matching virtual switch identifiers. In the illustrated example, the matching virtual switch identifiers of the virtual switches on a given virtual subring is used as the virtual ring label.
The virtual RPR subring (VRPR-S) port is established by allocating a physical RPR port (not shown) to a virtual switch with a specified bandwidth. Bandwidth may be allocated to each virtual RPR subring according to the methods defined in IEEE 802.17, and the total bandwidth allocated to the virtual RPR subrings may not exceed the bandwidth of the physical RPR ring. In some embodiments, bandwidth allocation is uniform; that is, the total bandwidth for traffic added at all the virtual switches on a given virtual RPR subring does not exceed the total bandwidth for the virtual RPR subring. Further, in some embodiments, bandwidth allocation is made in a spatially aware manner; that is, each span of the virtual RPR subring between a pair of virtual switches on the subring does not exceed the total bandwidth for the virtual RPR subring.
Traffic from the virtual switches 320a-1, 320a-2, 320a-3 are added to the same physical communications path 310r1. This traffic is divided into multiple virtual subrings 330r1-1, 330r1-2, 330r1-3 corresponding to the virtual switches 320a-1, 320a-2, 320a-3. All of the virtual subrings 330r1-1, 330r1-2, 330r1-3 traveling on the physical communications path 310r1 travel through a multicast tunnel 335r1. It should be noted that other traffic, such as a unicast tunnel 340r1, may also exist on the physical communications path 310r1.
Traffic coming into the physical switch 305a from the multicast tunnel 335r1 on the physical communications path 310r1 is inspected by the virtual switches 320a-1, 320a-2, 320a-3. Traffic traveling on virtual subring 330r1-1 is copied at virtual switch A1320a-1 and sent out of the physical switch 305a on a corresponding physical port 345a-1. Likewise, traffic traveling on virtual subrings 330r1-2 and 330r1-3 are copied at virtual switches A2320a-2 and A3320a-3, respectively, and sent out of the physical switch 305a on corresponding physical ports 345a-2 and 345a-3.
The modified traffic is then sent to the RPR block 520 (515). The RPR block 520 determines whether the traffic is multicast traffic by examining the tunnel label (521). If the traffic is not multicast, then a destination RPR address is determined by searching an address label mapping table (523). The traffic is then encapsulated with an RPR frame having a unicast RPR address and flooding disabled (524) and added to the RPR ring (526). If the traffic is multicast, then the traffic is encapsulated with an RPR frame having a multicast RPR address and flooding enabled (525) and added to the RPR ring (526).
The virtual switch 620 determines whether the frame is multicast traffic by examining the tunnel label (621 and 622). If the frame is not multicast traffic, the virtual switch takes further action according to a label rule table (623); however, if the frame is multicast traffic, then the tunnel label is removed (624). The virtual switch 620 then determines whether the virtual ring label is the same as the virtual switch identifier (625). If it is not the same, then the frame is discarded (626); however, if the virtual ring label and the identifier of the virtual switch match, then the virtual ring label is removed from the frame (627), and the underlying payload is forwarded to a port based on a forwarding table (628).
While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.
It should be understood that the flow diagrams of
The invention is applicable to any network topology as long as a ring network, such as a Synchronous Optical Network (SONET) ring network, is established. Further, the ring network example may use various Layer 1 protocols, such as Unidirectional Path Switched Ring (UPSR) or Bidirectional Line Switched Ring (BLSR) protocols.