Abstract:
A method and corresponding apparatus allows multiple virtual switches in a physical switch to share one physical Resilient Packet Ring (RPR) in an RPR network. Modules in the multiple virtual switches add multicast information to traffic to direct the traffic along a common path to other physical switches on the ring, and modules in the virtual switches inspect traffic to determine whether the traffic is directed to the respective virtual switch. Multiple virtual RPR subrings are made available in a single physical ring, increasing usefulness of virtual switches formerly only able to support multiple tributary connections to other networks but not able to share a single ring network communications path. Sharing a single communications path increases overall network bandwidth, and at least one implementation allows for spatial reuse.

Description:
BACKGROUND OF THE INVENTION 
       [0001]    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. 
       SUMMARY OF THE INVENTION 
       [0002]    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. 
         [0003]    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. 
         [0004]    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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    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. 
           [0006]      FIG. 1  is a network diagram illustrating a Resilient Packet Ring (RPR) network having four physical switches. 
           [0007]      FIG. 2  is a network diagram illustrating an RPR network having four physical switches, each configured with three virtual switches. 
           [0008]      FIG. 3  is a detailed block diagram illustrating a physical switch in an RPR network configured with three virtual switches. 
           [0009]      FIG. 4  is a header diagram illustrating example tunnel and virtual ring labels that are added to traffic to be transmitted over virtual RPR subrings (VRPR-S). 
           [0010]      FIGS. 5A and 5B  are flow diagrams illustrating adding information to traffic to be transmitted over virtual RPR subrings (VRPR-S). 
           [0011]      FIGS. 6A and 6B  are flow diagrams illustrating handling network traffic received from virtual RPR subrings (VRPR-S). 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0012]    A description of example embodiments of the invention follows. 
         [0013]      FIG. 1  is a network diagram of a Resilient Packet Ring (RPR) network (“RPR ring”)  100 , also referred to herein simply as a “ring.” The ring  100  has four physical switches  105   a - d  coupled by two counter-rotating communications paths in this example, Ringlet  1   110   r   1  and Ringlet  2   110   r   2 . Traffic  115   r   1  on Ringlet  1   110   r   1  travels clockwise around the ringlet  110   r   1 , and traffic  115   r   2  on Ringlet  2   110   r   2  travels counterclockwise around the ringlet  110   r   2 . The terms “traffic” and “communications” are synonymous as used herein. The term “traffic” can be packets or frames, which are also synonymous as used herein. 
         [0014]    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&#39;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. 
         [0015]    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. 
         [0016]    At a given station, the destination MAC address of the RPR header is examined. If the destination address of the frame&#39;s RPR header is the same as the station&#39;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&#39;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&#39;s address, then the frame will be dropped, thus, preventing an infinite loop. 
         [0017]    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. 
         [0018]    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. 
         [0019]    Today&#39;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. 
         [0020]    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. 
         [0021]    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. 
         [0022]    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. 
         [0023]    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. 
         [0024]    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. 
         [0025]    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. 
         [0026]      FIG. 2  is a network diagram that illustrates an RPR network  200  with an example embodiment of the present invention. The ring network  200  has four physical switches  205   a - d  coupled by two counter-rotating communications paths  210   r   1 ,  210   r   2 . Each physical switch  205   a - d  is configured with three virtual switches  220   a - 1 , 2 , 3 ,  220   b - 1 , 2 , 3 ,  220   c - 1 , 2 , 3 , and  220   d - 1 , 2 , 3 , and each communications path  210   r   1 ,  210   r   2  is logically separated into three virtual subrings  230   r   1 - 1 , 2 , 3 ,  230   r   2 - 1 , 2 , 3  corresponding to the virtual switches. 
         [0027]    In the illustrated ring network  200 , a given virtual subring  230   r   1 - 1 , 2 , 3 ,  230   r   2 - 1 , 2 , 3  carries traffic  215   r   1 ,  215   r   2  between virtual switches within the same group but at different locations on the ring network. For example, traffic  215   r   1 ,  215   r   2  coming into virtual switch A 1   220   a - 1  on physical switch A  205   a  is sent to virtual switches B 1   220   b - 1 , C 1   220   c - 1 , and D 1   220   d - 1  in physical switches B  205   b,  C  205   c,  and D  205   d,  respectively, via subring  230   r   1 - 1 . This is the case because virtual switches A 1   220   a - 1 , B 1   220   b - 1 , C 1   220   c - 1 , and D 1   220   d - 1  share the same virtual switch identifier and, therefore, share the same virtual subring  230   r   1 - 1 . Likewise, virtual switches A 2   220   a - 2 , B 2   220   b - 2 , C 2   220   c - 2 , and D 2   220   d - 2  share virtual subring  230   r   1 - 2 , and virtual switches A 3   220   a - 3 , B 3   220   b - 3 , C 3   220   c - 3 , and D 3   220   d - 3  share virtual subring  230   r   1 - 3 . 
         [0028]    The virtual subrings  230   r   1 - 1 , 2 , 3 ,  230   r   2 - 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. 
         [0029]    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. 
         [0030]      FIG. 3  is a block diagram that illustrates a physical switch  305   a  configured with three virtual switches  320   a - 1 ,  320   a - 2 ,  320   a - 3  according to an embodiment of the present invention. For the sake of simplicity, only one of the dual counter-rotating rings is shown. Packets  350  coming into the physical switch  305   a  on physical port  345   a - 1  are handled by a virtual switch A 1   320   a - 1 . A module  325   a - 1  in the virtual switch A 1   320   a - 1  adds multicast information to the traffic to add the traffic to the corresponding virtual subring  330   r   1 -l. Likewise, packets  350  coming into the physical switch  305   a  on other physical ports  345   a - 2  and  345   a - 3  are handled by other virtual switches A 2   320   a - 2  and A 3   320   a - 3 , respectively. Modules  325   a - 2  and  325   a - 3  in virtual switches A 2   320   a - 2  and A 3   320 - a - 3  add multicast information to the traffic in order to add the traffic to the corresponding virtual subrings  330   r   1 - 2 ,  330   r   1 - 3 . It should be noted that paths  355   a - 1 ,  355   a - 2 , and  355   a - 3  through the physical switch  305   a  are logical paths and may travel over the same physical path within the physical switch  305   a.    
         [0031]    Traffic from the virtual switches  320   a - 1 ,  320   a - 2 ,  320   a - 3  are added to the same physical communications path  310   r   1 . This traffic is divided into multiple virtual subrings  330   r   1 - 1 ,  330   r   1 - 2 ,  330   r   1 - 3  corresponding to the virtual switches  320   a - 1 ,  320   a - 2 ,  320   a - 3 . All of the virtual subrings  330   r   1 - 1 ,  330   r   1 - 2 ,  330   r   1 - 3  traveling on the physical communications path  310   r   1  travel through a multicast tunnel  335   r   1 . It should be noted that other traffic, such as a unicast tunnel  340   r   1 , may also exist on the physical communications path  310   r   1 . 
         [0032]    Traffic coming into the physical switch  305   a  from the multicast tunnel  335   r   1  on the physical communications path  310   r   1  is inspected by the virtual switches  320   a - 1 ,  320   a - 2 ,  320   a - 3 . Traffic traveling on virtual subring  330   r   1 - 1  is copied at virtual switch A 1   320   a - 1  and sent out of the physical switch  305   a  on a corresponding physical port  345   a - 1 . Likewise, traffic traveling on virtual subrings  330   r   1 - 2  and  330   r   1 - 3  are copied at virtual switches A 2   320   a - 2  and A 3   320   a - 3 , respectively, and sent out of the physical switch  305   a  on corresponding physical ports  345   a - 2  and  345   a - 3 . 
         [0033]      FIG. 4  is a header diagram illustrating example multicast tunnel and virtual ring labels that are added to traffic to be transmitted over a virtual RPR subring of the physical RPR ring according to the present invention. This multicast information includes a tunnel label  410  and a virtual ring label  420 . The tunnel label may be twenty bits in length, with four bits  415  indicating that the traffic is multicast traffic. The remaining bits are reserved. The virtual ring label  420  may be twenty bits in length, with five bits  425  indicating the virtual ring identifier (VRID), and twelve bits  430  indicating an optional virtual local area network identifier (S-VID). The remaining bits are reserved. Generally, the VRID is the same as the virtual switch identifiers (VSIDs) of the virtual switches that share the virtual RPR subring, allowing the automatic creation of virtual RPR subrings when assigning a physical RPR port to a virtual switch; however, a different VRID may be assigned to support the interconnection of virtual RPR subrings with different physical RPR rings. 
         [0034]      FIGS. 5A and 5B  are flow diagrams that illustrate adding the above information to traffic at a virtual switch in order to transmit the traffic over the virtual RPR subrings according to an embodiment of the present invention. A virtual switch  510  receives traffic from an associated physical port and determines to what port to forward the traffic by searching a forwarding table based on a destination MAC address ( 511 ). The virtual switch  510  then determines whether the port to which the traffic is to be forwarded is a virtual RPR subring port ( 512 ). If not, the traffic is forwarded to the determined port without modification ( 513 ); however, if the determined port is a virtual subring port, then a tunnel label indicating multicast traffic and a virtual ring label indicating the virtual switch identifier is added to the traffic ( 514 ). 
         [0035]    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 ). 
         [0036]      FIGS. 6A and 6B  are flow diagrams that illustrate handling network traffic received at a virtual switch from the virtual RPR subrings according to the present method and apparatus. Upon receiving an RPR frame, the RPR block  610  determines whether flooding has been enabled for the traffic ( 611  and  612 ). If it has been enabled, then the RPR payload is copied ( 613 ) and forwarded to the virtual switch  620  ( 618 ); however, if flooding has not been indicated, then the RPR block  610  determines whether the destination MAC address in the overhead of the RPR frame is the same as its own MAC address ( 614  and  615 ). If it is not the same, then the frame is discarded ( 616 ); however, if the addresses match, then the RPR payload is copied ( 617 ) and forwarded to the virtual switch  620  ( 618 ). 
         [0037]    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 ). 
         [0038]    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. 
         [0039]    It should be understood that the flow diagrams of  FIGS. 5A ,  5 B,  6 A, and  6 B are examples that can include more or fewer components, be partitioned into subunits, or be implemented in different combinations. Moreover, the flow diagrams may be implemented in hardware, firmware, or software. If implemented in software, the software may be written in any software language suitable for use in networks as illustrated in  FIGS. 1-3  with traffic having overhead information as illustrated in  FIG. 4 . The software may be embodied on any form of computer readable medium, such as RAM, ROM, or magnetic or optical disk, and loaded and executed by generic or custom processor(s). 
         [0040]    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.