Wednesday, December 30, 2009

United States Patent 7,640,076
WWW.USPTO.GOV
Olson
December 29, 2009

Remote control rover configured for viewing and manipulating objects

Abstract

A remotely controlled roving vehicle comprises a claw assembly and a video camera. The claw assembly includes a main body and a plurality of grasping member. A first end of each one of the grasping members is movably mounted on the main body for enabling a second end of each one of the grasping members to be moved between an open position and a closed position. The video camera includes an image-receiving portion that is mounted on the main body. A second end of each one of the grasping members is within a field of view of the video camera. A lens of the video camera is centrally located with respect to the first ends of the grasping members. The first end of each one of the grasping members is pivotally mounted on the main body. The main body is rotatable about a longitudinal axis thereof.
Inventors: Olson; Bradley Darrel (Fort Wayne, IN)
Appl. No.: 10/977,745
Filed: October 29, 2004

Current U.S. Class: 700/259 ; 700/245
Current International Class: G06F 19/00 (20060101)
Field of Search: 700/245-259
References Cited [Referenced By]
U.S. Patent Documents

3775765 November 1973 Di Piazza et al.
4460826 July 1984 Pryor
4621562 November 1986 Carr et al.
4827956 May 1989 Toot
4993912 February 1991 King et al.
5219264 June 1993 McClure et al.
5263809 November 1993 Kent
5413454 May 1995 Movsesian
5416321 May 1995 Sebastian et al.
5550953 August 1996 Seraji
5823590 October 1998 Forrest et al.
6272396 August 2001 Taitler
6292713 September 2001 Jouppi et al.
6377872 April 2002 Struckman
6450557 September 2002 Martinez
6704619 March 2004 Coleman et al.
6816755 November 2004 Habibi et al.
7096090 August 2006 Zweig
7174238 February 2007 Zweig
7289884 October 2007 Takahashi et al.
7363844 April 2008 Barton
7415321 August 2008 Okazaki et al.
2005/0096792 May 2005 Watanabe et al.
2006/0045679 March 2006 Ostendorff
2006/0095161 May 2006 Olson
2007/0039831 February 2007 Townsend
Primary Examiner: Black; Thomas G
Assistant Examiner: Louie; Wae
Attorney, Agent or Firm: Galasso; Raymond M. Galasso & Associates, L.P.
WWW.GAPATENTS.COM

Claims


What is claimed is:

1. A remotely controlled roving vehicle, comprising: a plurality of wheels connected to a drive means and a steering means; a control apparatus; a cable, wherein said cable is operably connected to the control apparatus and the roving vehicle; a claw assembly including a main body and a plurality of grasping members, wherein a first end of each one of said grasping members is movably mounted on the main body for enabling a second end of each one of said grasping members to be moved between an open position and a closed position; said the plurality of grasping members includes a first pair of grasping members and a second pair of grasping members said first pair of grasping members being different in configuration than the second pair of grasping members; and a video camera having an image-receiving portion thereof mounted on the main body, wherein the second end of each one of said grasping members is within a field of view of the video camera; and wherein the lens of the video camera is centrally located with respect to the first ends of said grasping members.

2. The roving vehicle of claim 1 wherein: the roving vehicle includes a chassis; and the claw assembly is translatable attached to the chassis.

3. The roving vehicle of claim 1 wherein the first end of each one of said grasping members is pivotally mounted on the main body.

4. The roving vehicle of claim 1 wherein the main body is rotatable about a longitudinal axis thereof.

5. The roving vehicle of claim 1, further comprising: means for forcibly moving said grasping members between the open position and the closed position.

6. The roving vehicle of claim 5 wherein said means for forcibly moving includes at least one of hydraulic means and electrical means.

7. The roving vehicle of claim 1, further comprising: means for forcibly moving said grasping members between the open position and the closed position; wherein a lens of the video camera is centrally located with respect to the first ends of said grasping members; wherein the first end of each one of said grasping members is pivotally mounted on the main body; wherein the main body is rotatable about a longitudinal axis there; wherein said means for forcibly moving includes at least one of hydraulic means and electrical means; wherein the plurality of grasping members includes a first pair of grasping members and a second pair of grasping members; wherein the first pair of grasping members is different in configuration than the second pair of grasping members; wherein the roving vehicle includes a chassis; and wherein the claw assembly is translatable attached to the chassis.

8. A remote control rover system, comprising: a plurality of wheels connected to a drive means and a steering means; a remotely controlled roving vehicle including a claw assembly having a main body, a plurality of grasping members movably mounted on the main body wherein said the plurality of grasping members includes a first pair of grasping members and a second pair of grasping members; said first pair of grasping members is different in configuration than the second pair of grasping members and a video camera having an image-receiving portion thereof mounted on the main body, wherein a first end of each one of said grasping members is movably mounted on the main body for enabling a second end of each one of said grasping members to be moved between an open position and a closed position and wherein the second end of each one of said grasping members is within a field of view of the video camera; wherein a lens of the video camera is centrally located with respect to the first ends of said grasping members; and a control apparatus including a video display, one or more user input devices comprised or one or more of a joystick having a plurality of actuation buttons, a trackball or a keyboard and a cable reel assembly having a length of cable provided thereon, wherein said cable is connected to the roving vehicle for enabling signals to be transmitted between the control apparatus and the roving vehicle, wherein the video display is coupled to the video camera through said cable for enabling images captured by the video camera to be visually displayed thereon, and wherein said at least one user input device is coupled to the roving vehicle through said cable for enabling movement of the roving vehicle and actuation of the claw assembly to be selectively controlled.

9. The system of claim 8 wherein the control apparatus and the roving vehicle jointly include means for forcibly moving said grasping members between the open position and the closed position.

10. The system of claim 9 wherein said means for forcibly moving includes at least one of hydraulic means and electrical means.

11. The system of claim 8, further comprising: means for rotating the reel for enabling said cable to be extended and retracting dependent upon said movement of the roving vehicle; wherein the control apparatus and the roving vehicle jointly include means for forcibly moving said grasping members between the open position and the closed position; wherein a lens for the video camera is centrally located with respect to the first ends of said grasping members; wherein the first end of each one of said grasping members is pivotally mounted on the main body; wherein said means for forcibly moving includes at least one of hydraulic means and electrical means; wherein the plurality of grasping members includes a first pair of grasping members and a second pair of grasping members; and wherein the first pair of grasping members is different in configuration than the second pair of grasping members.

12. A remote control rover system, comprising: a remotely controlled roving vehicle including a claw assembly having a main body, a plurality of grasping members movably mounted on the main body said plurality of grasping members includes a first pair of grasping members and a second pair of grasping members; wherein said first pair of grasping members is different in configuration than the second pair of grasping members and a video camera having an image-receiving portion thereof mounted on the main body, wherein a first end of each one of said grasping members is movably mounted on the main body for enabling a second end of each one of said grasping members to be moved between an open position and a closed position and wherein the second end of each one of said grasping members is within a field of view of the video camera; a control apparatus including interconnect means coupled between the control apparatus and the roving vehicle for enabling interaction there between, visual display means and user input means, wherein said visual display means is configured for enabling images captured by the video camera to be visually displayed, and wherein said user input means is configured for enabling movement of the roving vehicle and actuation of the claw assembly to be selectively controlled; and a plurality of user input devices comprised of a joystick having a plurality of actuation buttons, a trackball and a keyboard.

13. The system of claim 12 wherein: a lens of the video camera is centrally located with respect to the first ends of said grasping members.

14. The system of claim 12 wherein: the control apparatus and the roving vehicle jointly include means for forcibly moving said grasping members between the open position and the closed position; and said means for forcibly moving includes at least one of hydraulic means and electrical means.

15. The system of claim 14, wherein: said interconnect means includes a reel having a length of cable provided thereon and means for rotating the reel for enabling said cable to be extending and retracting dependent upon said movement of the roving vehicle; and said visual display means includes a visual display.
Description


FIELD OF THE DISCLOSURE

The disclosures made herein relate generally to remote control rover systems and, more particularly, to remotely controlled roving vehicle configured for viewing and manipulating objects.

BACKGROUND

Quite often the need arises for placement of items in, retrieval of items from and manipulation of items within difficult to access locations and/or dangerous locations. Examples of such locations include fields of debris, underground cavities, pipes of systems, etc. Accordingly, in some cases, the physical location is the primary cause for such danger while in other cases it is the item being manipulated that is the primary cause for such danger.

Conventional approaches for such placement, retrieval and/or manipulation expose the item, the person and/or access equipment to a potentially dangerous situation. Additionally, such conventional approaches are sometimes limiting in that they do not provide sufficient equipment power (e.g., hydraulic power) at required distant locations. For example, some applications may require a magnitude of grasping force that is better achievable via hydraulic actuation as opposed to electrical actuation.

Therefore, a remotely controlled rover system that overcomes limitations and drawbacks associated with conventional rover systems and approaches for remotely facilitating placement, retrieval and/or manipulation of items would be useful, advantageous and novel.

SUMMARY OF THE DISCLOSURE

In one embodiment, a remotely controlled roving vehicle comprises a claw assembly and a video camera. The claw assembly includes a main body and a plurality of grasping members. A first end of each one of the grasping members is movably mounted on the main body for enabling a second end of each one of the grasping members to be moved between an open position and a closed position. An image-receiving portion of the video camera is mounted on the main body. The second end of each one of the grasping members is within a field of view of the video camera.

In another embodiment, a remotely controlled rover system comprises a remotely controlled roving vehicle and a control apparatus. The claw assembly includes a main body, a plurality of grasping members mounted on the main body and a video camera having an image-receiving portion thereof mounted on the main body. A first end of each one of the grasping members is movably mounted on the main body for enabling a second end of each one of the grasping members to be moved between an open position and a closed position. The second end of each one of the grasping members is within a field of view of the video camera. The control apparatus includes a video display, a user input device and a cable reel assembly having a length of cable provided thereon. The cable is connected to the roving vehicle for enabling signals to be transmitted between the control apparatus and the roving vehicle. The video display is coupled to the video camera through the cable for enabling images captured by the video camera to be visually displayed thereon. The user input device is coupled to the roving vehicle through the cable for enabling movement of the roving vehicle and actuation of the claw assembly to be selectively controlled.

In another embodiment, a remotely controlled rover system comprises a remotely controlled roving vehicle including a claw assembly and a control apparatus. The claw assembly includes a main body, a plurality of grasping members movably mounted on the main body and a video camera having an image-receiving portion thereof mounted on the main body. A first end of each one of the grasping members is movably mounted on the main body for enabling a second end of each one of the grasping members to be moved between an open position and a closed position. The second end of each one of the grasping members is within a field of view of the video camera. The control apparatus includes interconnect means coupled between the control apparatus and the roving vehicle for enabling interaction therebetween, visual display means and user input means. The visual display means is configured for enabling images captured by the video camera to be visually displayed. The user input means is configured for enabling movement of the roving vehicle and actuation of the claw assembly to be selectively controlled.

In operation, an operator use user input means (e.g., a keyboard, trackball, joystick and the like) and visual display (e.g., a video display that enables the camera's field of view to be displayed) for facilitating movement of the rover and actuation of the claw assembly. Through appropriate input commands, the rover is moved along a visually confirmed path (i.e., as visually confirmed via the video camera and video display) and the claw assembly is controlled for manipulating (i.e., grasping, ungrasping rotating, etc) a manipulated item.

Correspondingly, it is a principal object of the inventive disclosures made herein to provide remotely controlled rovers and systems that overcome limitations and drawbacks associated with conventional rovers, systems and approaches for remotely facilitating placement, retrieval and/or manipulation of items. Specifically, such rovers and systems dramatically reduce the dangers associated with placement, retrieval and/or manipulation of items in dangerous environments and/or situations. Additionally, such rovers and systems are advantageous in that they provide useful equipment power (e.g., hydraulic power) at required distant locations. For example, a hydraulic actuation of the claw assembly may be implemented for providing high clamping force capability.

Turning now to specific embodiments of the inventive disclosures made herein, in at least one embodiment of the inventive disclosures made herein, a video camera lens is centrally located with respect to the first ends of the grasping members.

In at least one embodiment of the inventive disclosures made herein, the first end of each one of the grasping members is pivotally mounted on the main body.

In at least one embodiment of the inventive disclosures made herein, the main body is rotatable about a longitudinal axis thereof.

In at least one embodiment of the inventive disclosures made herein, means for forcibly moving the grasping members between the open position and the closed position is provided.

In at least one embodiment of the inventive disclosures made herein, the means for forcibly moving includes at least one of hydraulic means and electrical means.

In at least one embodiment of the inventive disclosures made herein, the plurality of grasping members includes a first pair of grasping members and a second pair of grasping members and the first pair of grasping members is different in configuration than the second pair of grasping members.

In at least one embodiment of the inventive disclosures made herein, a first pair of grasping members is of a first size and a second pair of grasping members is of a second size

In at least one embodiment of the inventive disclosures made herein, the interconnect means includes a reel having a length of cable provided thereon.

In at least one embodiment of the inventive disclosures made herein, means is provided for rotating the reel for enabling the cable to be extending and retracting dependent upon the movement of the roving vehicle.

In at least one embodiment of the inventive disclosures made herein, the visual display means includes a visual display.

In at least one embodiment of the inventive disclosures made herein, the user input means includes a non-keyed user device such as a joystick or trackball.

In at least one embodiment of the inventive disclosures made herein, the roving vehicle includes a chassis and the claw assembly is translatably attached to the chassis.

These and other objects and embodiments of the inventive disclosures made herein will become readily apparent upon further review of the following specification and associated drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an embodiment of a remotely controlled rover system in accordance with the inventive disclosures made herein.

FIG. 2 depicts an embodiment of a claw assembly in accordance with the inventive disclosures made herein.

FIG. 3 depicts an embodiment of a system component schematic of the rover system depicted in FIG. 1.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an embodiment of a remotely controlled rover system 100 in accordance with the inventive disclosures made herein. The remotely controlled rover system 100 includes a remotely controlled roving vehicle 102 (i.e., the roving vehicle 102) and a control apparatus 104. The roving vehicle 102 is operably connected to the control apparatus 104 by a cable 106.

The roving vehicle 102 includes means for movement 107, a claw assembly 108 and a video camera 110. Functionally, the drive means and the steering means enable selective movement of the roving vehicle 102 between locations as directed by a remote operator. As depicted, one embodiment of the means for movement 107 includes a plurality of wheels 112 and is configured in a manner wherein one or more of the wheels 112 is connected to a drive means and a steering means (not specifically shown). Examples of the drive means include an electric motor, a hydraulic motor and the like. Examples of the steering means include a rack/pinion/servo arrangement, a spindle/servo arrangement, a dual transmission/clutch arrangement and the like. Such examples of the steering means allow for turning of at least one of the wheels 112 or turning through differential speed of two or more of the wheels 112. Other embodiments of the means for movement include one or more tracks and a mechanism allowing for differentiation speed of one or more of the tracks.

The claw assembly 108 includes a main body 114 and a plurality of grasping members 116 and a video camera 110. The plurality of grasping members 116 is movably mounted on the main body 114. In the depicted embodiment, a first end 120 of each one of the grasping members 116 is pivotally mounted (i.e., movable mounted) on the main body 114. Through such pivoting ability, a second end 122 of each one of the grasping members 116 is movable between a position in which an item is released from the grasping members 116 (i.e., a respective open position) and a position in which one or more of the grasping members 116 are engaged with the item (i.e., a respective closed position).

It is disclosed herein that a various embodiments of means for forcibly moving the grasping members 116 between the open position and the closed position may be implemented. In one embodiment, a means for forcibly moving is a hydraulic-type means that includes components such as a hydraulic pump, a reservoir for hydraulic oil, a hydraulic actuators and other associated components such as hydraulic lines, valves pressure regulators, etc. The hydraulic means may be entirely located on the roving vehicle 102 (e.g., hydraulic fluid/hydraulic pressure is not communicated through the cable 106) or may be segmented between the roving vehicle 102 and the control apparatus 104 (e.g., the pump is located at the control apparatus 104 and hydraulic fluid/fluid pressure is communicated through the cable 106). In another embodiment, the means for forcibly moving is an electro-mechanical type means that includes components such as electrical solenoids, cams, levers, and the like connected to the grasping members 116.

The video camera 110 is attached to the roving vehicle 102 in a manner wherein the second end 122 of each one of the grasping members 116 is within a field of view of the video camera 110. In one embodiment, an image-receiving portion of the video camera 110 includes a lens and light receptor circuitry and is mounted on the main body 114 of the claw assembly 108. To provide for the second end 122 of each one of the grasping members 116 to be within the field of view of the video camera 110, the lens of the video camera 110 is preferably, but not essentially, centrally located on the main body 114 with respect to the first ends 120 of the grasping members 116.

In one embodiment, the claw assembly 108 is preferably configured for enabling translation of the claw assembly 102 with respect to a chassis (not specifically shown) of the roving vehicle 102. For example, the claw assembly 102 is mounted on the chassis via means for enabling translation of the claw assembly with respect to the chassis. Such translation includes vertical translation, horizontal translation and/or longitudinal translation. Examples of the means for movement include a plurality of sliders mounted between the chassis and the claw assembly 102 and an actuation means such as a hydraulic actuation means or an electro-mechanical actuation means.

As depicted in FIG. 2, the claw assembly 108 is rotatable about a longitudinal reference axis L (e.g., the longitudinal axis of the main body 114 and/or camera lens). Additionally, the plurality of grasping members 116 includes a first pair P1 of grasping members and a second pair P2 of grasping members. In one embodiment, the first pair P1 of grasping members is different in configuration than the second pair P2 of grasping members. Examples of such difference in configuration include, but are not limited to, size, shape, material, clamping strength, etc.

Referring now to FIGS. 1 and 3, the control apparatus 104 is configured for controlling movement of the roving vehicle 102, movement of the claw assembly 108 and, optionally, adjustment of the relative field of view of the video 110. The control apparatus 104 includes a video display 124, a plurality of user input devices (i.e., a joystick 126 having a plurality of actuation buttons 128, a trackball 130, a keyboard 132), a cable reel assembly 134 and various logic components. The joystick 126 and the trackball 130 are examples of non-keyed user input devices.

The cable reel assembly 134 has a length of the cable 106 provided thereon. The cable 106 is connected to the roving vehicle 102 for enabling signals to be transmitted between the control apparatus 104 and the roving vehicle 102. The video display 124 is connected to the video camera 110 through the cable 106 for enabling images captured by the video camera 110 to be visually displayed. The user input devices are connected to the roving vehicle 102 through the cable for enabling movement of the roving vehicle 102 and actuation of the claw assembly 108 to be selectively controlled. In one embodiment, a means for rotating the reel (e.g., a motor assembly) is provided for enabling the cable 106 to be extending and retracting dependent upon movement of the roving vehicle 102.

The various logic components of the control apparatus 104 facilitate system functionality such as signal interfacing between the roving vehicle 102 and the control apparatus 104, cable reel control, displaying of video signals generated by the video camera 110, and processing of inputs made by the user via the user interface devices. As depicted in FIG. 3, one embodiment of the various logic components of the control apparatus 104 include a cable reel controller 136, a video controller 138, a user input device controller 140 and a central processing module 142. The central processing module 142 is connected between the rover vehicle 102, the cable reel controller 136, the video controller 138 and the user input device controller 140 and facilitates processing of input and output information (e.g., identification, processing, interpretation and/or transmission signals).

The roving vehicle 102 includes an integrated controller 144 connected to the means for movement 107, the claw assembly 108 and the video camera 110. The integrated controller 144 is further connected to the control apparatus 104 through the central processing module 142. The integrated controller 144 facilitates rover-based information processing functionality associated with camera operation, claw assembly operation, roving vehicle movement and signal transmission between the roving vehicle 102 and the control apparatus 104.

In another embodiment of the rover system 100 (not specifically shown), remote control functionality is facilitated in a wireless manner wherein the control apparatus 104 and the roving system 102 include respective transceivers this manner, signals may be transmitted between the control apparatus 104 and the roving vehicle 102.

In the preceding detailed description, reference has been made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments, and certain variants thereof, have been described in sufficient detail to enable those skilled in the art to practice embodiments of the inventive disclosures made herein. It is to be understood that other suitable embodiments may be utilized and that logical, mechanical, chemical and electrical changes may be made without departing from the spirit or scope of such inventive disclosures. To avoid unnecessary detail, the description omits certain information known to those skilled in the art. The preceding detailed description is, therefore, not intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the appended claims. For more information go to WWW.GAPATENTS.COM or WWW.GOOGLE.COM.

Monday, December 28, 2009

United States Patent 7,636,354
WWW.USPTO.GOV
Diouf
December 22, 2009

Deriving passive optical network port identifiers

Abstract

A method in accordance with the present invention comprises identifying a M-bit multicast address and deriving a N-bit PON port identifier from the M-bit multicast address. Identifying the M-bit multicast address and deriving the N-bit PON port identifier are performed at an Optical Line Terminal (OLT) of a Passive Optical Network (PON). The N-bit PON port identifier has fewer bits than the M-bit multicast address. Deriving the N-bit PON port identifier includes mapping N-1 Least Significant Bits (LSB) of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier and setting a 1 Most Significant Bit (MSB) of the N-bit PON port identifier to a bit setting that designates the N-bit PON port identifier as being a multicast port identifier.
Inventors: Diouf; Leopold (Raleigh, NC)
Assignee: Alcatel Lucent (Paris, FR)
Appl. No.: 11/231,186
Filed: September 20, 2005
Related U.S. Patent Documents

Application Number Filing Date Patent Number Issue Date
60634866 Dec., 2004

Current U.S. Class: 370/390 ; 370/432
Current International Class: H04L 12/26 (20060101); H04J 3/26 (20060101)
Field of Search: 370/432,390
References Cited [Referenced By]
U.S. Patent Documents

5566170 October 1996 Bakke et al.
6065061 May 2000 Blahut et al.
2004/0028409 February 2004 Kim et al.
2004/0057462 March 2004 Lim et al.
2004/0196862 October 2004 Song et al.

Other References

Newton's Telecom Dictionary, 13 th Edition, 1998. http://www.trynci.com/cat/ref5.htm. cited by examiner .
ITU-T: Telecommunication Standardization Sector of ITU; G.984.4 (Jun. 2004); Series G: Transmission Systems and Media, Digital Systems and Networks; Chapter 6.5; pp. 1-13. cited by other .
ITU-T: Telecommunication Standardization Sector of ITU; G.984.3 (Feb. 2004); Series G: Transmission Systems and Media, Digital Systems and Networks; Chapters 3.16, 9.2.3.14; pp. 1-107. cited by other.

Primary Examiner: Rao; Seema S.
Assistant Examiner: Russell; Wanda Z
Attorney, Agent or Firm: Galasso & Associates WWW.GAPATENTS.COM

Parent Case Text


CROSS REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to co-pending U.S. Provisional Patent application having Ser. No. 60/634,866 filed Dec. 11, 2004 entitled "Deriving PON Multicast Port or PON Multicast VP from IP or MAC Multicast Address", having a common applicant herewith and being incorporated herein in its entirety by reference.
Claims


What is claimed is:

1. A method using a network element comprising: identifying a M-bit multicast address; and deriving a N-bit PON (Passive Optic Network) port identifier from the M-bit multicast address, wherein the N-bit PON port identifier has fewer bits than the M-bit multicast address and wherein said deriving the N-bit PON port identifier includes mapping N-1 Least Significant Bits (LSB) of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier and setting a 1 Most Significant Bit (MSB) of the N-bit PON port identifier to a bit setting that designates the N-bit PON port identifier as being a multicast port identifier.

2. The method of claim 1 wherein the M-bit multicast address is an Internet Protocol (IP) multicast address.

3. The method of claim 1 wherein the M-bit multicast address is a Media Access Control (MAC) multicast address.

4. The method of claim 1 wherein the bit setting is a bit setting of 1.

5. The method of claim 1 wherein said identifying and said deriving are performed at both an Optical Line Terminal (OLT) and an Optical Network Termination Unit (ONTU) of a Passive Optical Network (PON).

6. The method of claim 1 wherein said deriving the N-bit PON port identifier is performed automatically by the network element without human intervention in response to said identifying the M-bit multicast address.

7. The method of claim 1 wherein: the M-bit multicast address is at least one of an IP multicast address and a MAC multicast address; the bit setting is a bit setting of 1; said identifying and said deriving are performed at both an OLT and an ONTU of a PON; and said deriving the N-bit PON port identifier is performed automatically without human intervention in response to said identifying the M-bit multicast address.

8. A method using a network element, comprising: identifying one of a 32-bit Internet Protocol (IP) multicast address and a 48-bit Media Access Control (MAC) multicast address; and deriving a 12-bit PON port identifier from said one of the 32-bit IP multicast address and the 48-bit MAC multicast address, wherein said deriving the 12-bit PON port identifier includes mapping 11 Least Significant Bits (LSB) of said one of the 32-bit IP multicast address and the 48-bit MAC multicast address to 11 LSB of the 12-bit PON port identifier and setting a 1 Most Significant Bit (MSB) of the 12-bit PON port identifier to a bit setting that designates the 12-bit PON port identifier as being a multicast port identifier.

9. The method of claim 8 wherein the bit setting is a bit setting of 1.

10. The method of claim 8 wherein: said deriving the 12-bit PON port identifier is performed automatically without human intervention in response to said identifying said multicast address; and said identifying and said deriving are performed at both an Optical Line Terminal (OLT) and an Optical Network Termination Unit (ONTU) of a Passive Optical Network (PON).

11. The method of claim 8 wherein: the bit setting is a bit setting of 1; said deriving the 12-bit PON port identifier is performed automatically without human intervention in response to said identifying said multicast address: said identifying and said deriving are performed at both an OLT and an ONTU of a PON.

12. A network element, comprising: at least one data processing device; memory connected to said at least one data processing device; and instructions accessible from said memory and processable by said at least one data processing device, wherein said instructions are configured for enabling said at least one data processing device to facilitate: identifying a M-bit multicast address; and deriving a N-bit PON port identifier from the M-bit multicast address, wherein the N-bit PON port identifier has fewer bits than the M-bit multicast address and wherein said deriving the N-bit PON port identifier includes mapping N-1 Least Significant Bits (LSB) of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier and setting a 1 Most Significant Bit (MSB) of the N-bit PON port identifier to a bit setting that designates the N-bit PON port identifier as being a multicast port identifier.

13. The network element of claim 12 wherein: the M-bit multicast address is a 32-bit Internet Protocol (IP) multicast address; and the N-bit PON port identifier is a 12-bit PON port identifier.

14. The network element of claim 13 wherein the bit setting is a bit setting of 1.

15. The network element of claim 12 wherein: the M-bit multicast address is a 48-bit Media Access Control (MAC) multicast address; and the N-bit PON port identifier is a 12-bit PON port identifier.

16. The network element of claim 15 wherein the bit setting is a bit setting of 1.

17. The network element of claim 12 wherein the bit setting is a bit setting of 1.

18. The network element of claim 12 wherein said identifying and said deriving are performed at both an Optical Line Terminal (OLT) and an Optical Network Termination Unit (ONTU) of a Passive Optical Network (PON).

19. The network element of claim 12 wherein said deriving the N-bit PON port identifier is performed automatically by the network element without human intervention in response to said identifying the M-bit multicast address.

20. The network element of claim 12 wherein: the M-bit multicast address is one of a 32-bit IP multicast address and 48-bit MAC multicast address; the N-bit PON port identifier is a 12-bit PON port identifier; the bit setting is a bit setting of 1; said identifying and said deriving are performed at both an OLT and an ONTU of a PON; and said deriving the N-bit PON port identifier is performed automatically without human intervention in response to said identifying the M-bit multicast address.
Description


FIELD OF THE DISCLOSURE

The disclosures made herein relate generally to Passive Optical Networks and, more particularly, to determining ports in Passive Optical Networks.

BACKGROUND

Support of Internet Protocol (IP) video poses numerous challenges on a Passive Optical Network (PON). One consideration from which such challenges arise is that IP video service is relatively high-demand in terms of bandwidth, thus leading to potential bandwidth allocation issues. Another consideration from which such challenges arise is that there are relatively frequent demands from video operators to support a greater number of IP video channels (e.g., IP television channels), which lead to relatively frequent changes in channel programming. Still another consideration from which such challenges arise is that the need exists for simultaneous support of multiple channels. Yet another consideration from which such challenges arise is that multiple set-top-boxes (STBs) in a subscriber premise are often tuned to the same channel.

Given the broadcast nature of PON signal transmissions, provision must be in place to minimize channel duplication on the PON. Bandwidth allocation for such channel duplication, as well as for the number of available channels, can adversely affect PON performance. To enhance bandwidth utilization in a PON providing IP video services, it is preferred to avoid broadcasting more than one copy of a particular channel regardless of how many viewers are actually watching that particular channel.

Therefore, a solution that addresses challenges associated with support of IP video on a PON would be useful and advantageous.

SUMMARY OF THE DISCLOSURE

Embodiments of the present invention address challenges associated with support of Internet Protocol (IP) video on a PON. More specifically, by automatically deriving a PON port identifier from a multicast address, embodiments of the present invention support multicast PON addresses (e.g., port-ids and Virtual Port Identifiers) in a manner that provides for efficient IP video on the PON and efficient bandwidth usage on the PON. In doing so, methods and equipment in accordance with the present invention address challenges associated with IP video service being relatively high-demand in terms of bandwidth, with demands from video operators to support a greater number of IP video channels, with the need for simultaneous support of multiple channels and with multiple set-top-boxes (STBs) in a subscriber premise being tuned to the same channel. Accordingly, the present invention advantageously enhances PON versatility and IP video appeal.

In one embodiment of the present invention, a method comprises identifying a M-bit multicast address and deriving a N-bit PON port identifier from the M-bit multicast address. The N-bit PON port identifier has fewer bits than the M-bit multicast address. Deriving the N-bit PON port identifier includes mapping N-1 Least Significant Bits (LSB) of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier and setting a 1 Most Significant Bit (MSB) of the N-bit PON port identifier to a bit setting that designates the N-bit PON port identifier as being a multicast port identifier.

In another embodiment of the present invention, a method comprises identifying a 32-bit IP multicast address or a 48-bit MAC multicast address and deriving a 12-bit PON port identifier from the 32-bit IP multicast address or from the 48-bit MAC multicast address, respectively. Deriving the 12-bit PON port identifier includes mapping 11 LSB of the 32-bit IP multicast address to 11 LSB of the 12-bit PON port identifier or mapping the mapping 11 LSB of the 48-bit MAC multicast address to the 11 LSB of the 12-bit PON port identifier and includes setting a 1 MSB of the 12-bit PON port identifier to a bit setting that designates the 12-bit PON port identifier as being a multicast port identifier.

In another embodiment of the present invention, a network element comprises one or more data processing devices, memory connected to the one or more data processing devices and instructions accessible from the memory and processable by the one or more data processing device. The instructions are configured for enabling the one or more data processing device to facilitate identifying a M-bit multicast address and deriving a N-bit PON port identifier from the M-bit multicast address. The N-bit PON port identifier has fewer bits than the M-bit multicast address. Deriving the N-bit PON port identifier includes mapping N-1 LSB of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier and setting a 1 MSB of the N-bit PON port identifier to a bit setting that designates the N-bit PON port identifier as being a multicast port identifier.

Turning now to specific aspects of the present invention, in at least one embodiment, the M-bit multicast address is an IP multicast address.

In at least one embodiment of the present invention, the M-bit multicast address is a MAC multicast address.

In at least one embodiment of the present invention, the bit setting is a bit setting of 1.

In at least one embodiment of the present invention, identifying and deriving are performed at a network element of a PON.

In at least one embodiment of the present invention, the network element is an Optical Line Terminal (OLT), an Optical Network Termination (ONT) or an Optical Network Unit (ONU).

In at least one embodiment of the present invention, deriving the PON port identifier is performed automatically by a network element of a PON without human intervention in response to identifying the multicast address.

These and other objects, embodiments advantages and/or distinctions of the present invention will become readily apparent upon further review of the following specification, associated drawings and appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an embodiment of a method in accordance with the present invention.

FIG. 2 depicts derivation of a 12-bit PON port identifier from a 32-bit IP multicast address.

FIG. 3 depicts derivation of a 12-bit PON port identifier from a 48-bit MAC multicast address.

FIG. 4 depicts a network element in accordance with the present invention.

DETAILED DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 depicts an embodiment of a method in accordance with the present invention, which is referred to herein as the method 100. The method 100 is configured for deriving a Passive Optical Network (PON) multicast port identifier from a multicast address. In this manner, the present invention enables the Optical Line Terminal (OLT) and Optical Network Termination (ONT) or Optical Network Unit (ONU) to individually and automatically derive a PON port or a PON Virtual Port (VP) between the OLT and ONT from the multicast address without provisioning. Through the use of such a method in accordance with the present invention, the present invention enables a single copy of a particular content (e.g., a particular television channel) to be provided on the PON regardless of how many subscribers are actually watching that particular channel, enhances the efficiency in which IP video on the PON is able to be provided and increases bandwidth usage efficiency on the PON.

For simplicity and clarity, the terms ONT and ONU shall both be referred to hereinafter as an Optical Network Termination Unit (ONTU). As is well known, an ONT and an ONU are similar devices that provide similar functionality. These devices provide interface functionality between the Customer Premise Equipment (CPE) and an OLT that serves that CPE. The primary distinction between an ONT and an ONU is their intended physical location and preferred application.

As depicted in FIG. 1, the method includes an operation 105 that is performed for identifying a M-bit multicast address. Examples of the M-bit multicast address include, but are not limited to, a 32-bit Internet Protocol (IP) multicast address and a 48-bit Media Access Control (MAC) multicast address. In response to identifying the M-bit multicast address, an operation 110 is performed for deriving a N-bit PON port identifier from the M-bit multicast address. The N-bit PON port identifier may represent a PON port or PON multicast VP. A 12-bit PON port identifier is an example of the N-bit PON port identifier. Thus, in accordance with the present invention, the N-bit PON port identifier has fewer bits than the M-bit multicast address.

Deriving the N-bit PON port identifier includes mapping at least two tasks. A first task 115 is performed for mapping N-1 Least Significant Bits (LSB) of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier. A second task 120 is performed for setting a 1 Most Significant Bit (MSB) of the N-bit PON port identifier to a bit setting that designates the N-bit PON port identifier as being a multicast port identifier. It is disclosed herein that the first task 115 and the second task 120 may be performed sequentially or in parallel. An operation 125 is then performed for providing the N-bit PON port identifier to a logic element of the PON, a hardware element of the PON and/or a human element of the PON such that the N-bit PON port identifier may be utilized for facilitating transmission of information (e.g., video signal information) via the PON.

FIG. 2 depicts derivation of a 12-bit PON port identifier from a 32-bit IP multicast address. The 4 MSB of the 32-bit IP multicast address are fixed, thus leaving the 28 LSB as being mappable. As depicted in FIG. 2, only the 11 LSB of the 12-bit PON port identifier are mapped because the 1 MSB of the 12-bit PON port identifier is set to a bit setting (i.e., a bit value) that designates the 12-bit PON port identifier as a multicast port identifier. A 12-bit PON port identifier provides for 4096 distinct port identifiers (i.e., 2^12 distinct port identifiers), which are standard values for the port-ids or VPI. However, this number of distinctive port identifiers is far more than any hardware would reasonably support in real implementation.

In accordance with the present invention, the bit setting that designates the 12-bit PON port identifier as a multicast port identifier is a bit setting of 1. In contrast, for designating the 12-bit PON port identifier as a generic port identifier for applications non-related to the present invention, the 1 MSB of the 12-bit PON port identifier would be set to a bit setting that designates the 12-bit PON port identifier as a generic port identifier (i.e., a bit setting of 0). Because use of the 1 MSB of the 12-bit PON port identifier is fixed, each PON can only support up to 2048 distinct IP TV channels (i.e., 2^11 distinct IP TV channels).

With only 11 LSB of the 12-bit PON port identifier being mappable, this means that only 11 bits of the 28 allocatable bits of the 32-bit IP multicast address can be mapped onto the PON port identifier. Accordingly, 17 bits of the 32-bit IP multicast address addressing capacity map to the same VP/port-ID (i.e., 131,072 (2^17) IP multicast addresses will map to the same VP/port-ID).

FIG. 3 depicts derivation of a 12-bit PON port identifier from a 48-bit MAC multicast address. The 24 MSB of the 48-bit MAC multicast address are fixed, thus leaving the 24 LSB as being mappable. As depicted in FIG. 3, only the 11 LSB of a 12-bit PON port identifier are mapped because the 1 MSB of the 12-bit PON port identifier is set to a bit setting (i.e., a bit value) that designates the 12-bit PON port identifier as a multicast port identifier. As mentioned above, a 12-bit PON port identifier provides for 4096 distinct port identifiers (i.e., 2^12 distinct port identifiers), which are standard values for the port-ids or VPI. However, this number of distinctive port identifiers is far more than any hardware would reasonably support in real implementation.

In accordance with the present invention, the bit setting that designates the 12-bit PON port identifier as a multicast port identifier is a bit setting of 1. In contrast, for designating the 12-bit PON port identifier as a generic port identifier for applications non-related to the present invention, the 1 MSB of the 12-bit PON port identifier would be set to a bit setting that designates the 12-bit PON port identifier as a generic port identifier (i.e., a bit setting of 0). Because use of the 1 MSB of the 12-bit PON port identifier is fixed, each PON can only support up to 2048 distinct MAC TV channels (i.e., 2^11 distinct MAC TV channels).

With only 11 LSB of the 12-bit PON port identifier are mappable, this means that only 11 bits of the 24 allocatable bits of the 48-bit MAC multicast address can be mapped onto the PON port identifier. Accordingly, 13 bits of the 48-bit MAC multicast address addressing capacity map to the same VP/port-ID (i.e., 8192 (2^13) MAC multicast addresses will map to the same VP/port-ID).

Referring now to FIG. 4, a network element in accordance with the present invention is depicted. The network element is referred to herein as the network element 200. The network element 200 includes a data processing device 205 (i.e., at least one data processing device), memory 210, a downstream traffic interface 215 and an upstream traffic interface 220. The data processing device 205, the memory 210, the downstream traffic interface 215 and the upstream traffic interface 220 are connected for enabling interaction therebetween. The processor is configured for carrying out-processing requirements for a host of different functionalities performed by the network element 200. One of these functionalities is PON port identifier derivation functionality in accordance with the present invention.

In the case of the network element 200 being an ONTU, the downstream traffic interface 215 enables the transmission of traffic to subscriber equipment and the upstream traffic interface enables the transmission of traffic to an OLT (e.g., via an ONTU). In the case of the network element 200 being an OLT, the downstream traffic interface 215 enables the transmission of traffic to an ONTU and the upstream traffic interface enables transmission of traffic to a central office or head-end.

Residing on the memory 210 is instruction 225 for, among other functionality, carrying out PON port identifier derivation functionality in accordance with the present invention. The instructions 225 are accessible from the memory and are processable by the data processing device 205. The instructions 225 are configured for enabling the data processing device to facilitate identifying a M-bit multicast address (e.g., a 32-bit IP multicast address or a 48-bit MAC multicasting address) and deriving a N-bit PON port identifier (e.g., a 12-bit PON port identifier) from the M-bit multicast address, such as was described above in reference to FIGS. 1-3. The N-bit PON port identifier has fewer bits than the M-bit multicast address. Deriving the N-bit PON port identifier includes mapping N-1 LSB of the M-bit multicast address to N-1 LSB of the N-bit PON port identifier and setting a 1 MSB of the N-bit PON port identifier to a setting that designates the N-bit PON port identifier as being a multicast port identifier.

In the preceding detailed description, reference has been made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the present invention may be practiced. These embodiments, and certain variants thereof, have been described in sufficient detail to enable those skilled in the art to practice embodiments of the present invention. It is to be understood that other suitable embodiments may be utilized and that logical, mechanical, chemical and electrical changes may be made without departing from the spirit or scope of such inventive disclosures. To avoid unnecessary detail, the description omits certain information known to those skilled in the art. The preceding detailed description is, therefore, not intended to be limited to the specific forms set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the appended claims. For more information go to WWW.GAPATENTS.COM or WWW.GOOGLE.COM.

Friday, December 18, 2009

United States Patent 7,429,023
WWW.USPTO.GOV
Morrow
September 30, 2008

Deck support

Abstract

Deck Support is an L-shaped bracket with a plurality of holes and a slot for fastening it to a house joist and the deck band board. Ideally, a user secures the first side of the L-shaped bracket to the house joist using nails and/or bolts through the plurality of holes and attaches the second side of the L-shaped bracket to the inside band of the house and band board of the deck utilizing a carriage bolt.
Inventors: Morrow; Michael L. (Damascus, MD)
Appl. No.: 11/540,888
Filed: September 29, 2006

Current U.S. Class: 248/300 ; 248/200; 248/316.1; 52/712; 52/715; D8/354
Current International Class: A47F 5/00 (20060101)
Field of Search: 248/300,27.1,316.1,309.1,313,154,220.1,200,65,339,317,223.1 D8/354,349,373 52/715,712,243,696,655.1,731.3
References Cited [Referenced By]
U.S. Patent Documents

2679911 June 1954 Bhend
2687864 August 1954 Kohler
3280527 October 1966 Faust
3718307 February 1973 Albanese
D237460 November 1975 Bordman
4163372 August 1979 Frye et al.
D257219 October 1980 Cook
4248398 February 1981 Doyel
D264423 May 1982 Naylor
D310520 September 1990 Bedard
5060891 October 1991 Nagy et al.
5240216 August 1993 Lin et al.
5366194 November 1994 Finney
5810303 September 1998 Bourassa et al.
5897086 April 1999 Condon
D431999 October 2000 Haltof
D434639 December 2000 Willett
D442471 May 2001 Willett
6462961 October 2002 Johnson et al.
6669156 December 2003 East et al.
D503330 March 2005 Murphy et al.
D520344 May 2006 Vejmarker
7053300 May 2006 Denier et al.
7172221 February 2007 Ferrara
D563770 March 2008 Payne, Jr.
2002/0047073 April 2002 Deciry et al.
2007/0199274 August 2007 Rice
2007/0210021 September 2007 Whitehead et al.
Primary Examiner: Wood; Kimberly
Attorney, Agent or Firm: Galasso; Raymond M. Galasso & Assoc. LP
WWW.GAPATENTS.COM

Claims


What is claimed is:

1. An L-shaped bracket comprising: (a) a first side made of steel that is approximately rectangular with a plurality of holes spaced approximately evenly throughout and a first square hole located in the upper outer corner, a second square hole located in the lower outer corner and a third square hole located in the lower inner corner; (b) a second side that is made of steel and is tapered from the top and bottom toward the center where a slot is located; (c) a tab located above the slot extending at a twenty degree angle inward from the second side; (d) said first side is approximately five inches long and five inches wide and said second side is approximately five inches long and three inches wide; and (e) said slot is approximately nine-sixteenths of an inch wide.
Description


CROSS REFERENCE TO RELATED APPLICATIONS

This Non-Provisional United States Patent Application does not claim priority to any United States Provisional Patent Applications or any foreign patent applications.

FIELD OF THE DISCLOSURE

The disclosures made herein relate generally to the new construction and home improvement industry. The invention discussed herein is in the general classification of deck attachment and safety devices.

BACKGROUND

Many individuals purchase homes with decks to enjoy the outdoors or host barbeques or other outdoor parties. Decks also enhance the amount of living space of a home. Often, a homeowner chooses to add a deck to a house after purchasing the house if one does not already exist.

Building a deck can be a difficult aspect of construction without the services of an accomplished carpenter. Even decks that are constructed by professionals can collapse for a variety of reasons. Deck collapses can kill or seriously injure persons on or under the deck. Traditionally, decks are attached to a house by using the house band board and the deck band board. The house band board does not provide adequate support in many cases for attaching the deck band board. The two band boards can peel away from one another causing deck instability or a potential collapse.

Hence, there is a need in the art for a convenient, inexpensive and effective device for attaching the deck band board to the house joists.

SUMMARY OF THE DISCLOSURE

Deck Support is a L-shaped bracket with a slot and a plurality of holes for fastening to a band board of a deck and the joist of a house.

The principal object of this invention is to provide a device that can safely secure a deck to a house.

Another object of this invention is to provide a device that can be easily installed by skilled craftsmen or layman.

Another object of this invention is to provide an affordable device for connecting the band board of a deck to the joist of a house.

Yet another object of this invention is to provide a device that can be retrofitted to existing decks.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a perspective view of the preferred embodiment of the present invention.

FIG. 2 depicts a cross-sectional view of the preferred embodiment of the invention cut along the line II-II of FIG. 1.

DETAILED DESCRIPTION OF THE DRAWINGS

The preferred embodiment of Deck Support is comprised of at least some of the following: a metal L-shaped bracket with a plurality of holes and a slot for fastening it to the house joist and deck band board.

FIG. 1 shows the preferred embodiment of the invention. An L-shaped bracket 1 has a first side 2 that is five inches long and five inches wide and a second side 3 that is five inches long and three inches wide at its widest part.

The first side 2 is approximately rectangular while the second side 3 tapers from the top and bottom and has a slot 6 in approximately the center. The slot 6 is approximately nine-sixteenths ( 9/16) of an inch wide and an inch and a half deep. A tab 20 is located on the top of the slot 6. A plurality of holes 4 is spaced evenly throughout the first side 2. Three square holes 5 with nine-sixteenths of an inch sides are located on the perimeter of the first side 2.

The plurality of holes 4 on the first side 2 is designed to permit nails to pass through the first side 2. The square holes 5 on the first side 2 are for insertion of carriage bolts and nuts for increased stability. The first side 2 and the second side 3 are made of metal, preferably steel for durability and strength.

FIG. 2 depicts a cross-sectional view of the preferred embodiment of the invention. The thickness of the first side 2 and second side 3 can be seen in greater detail. Ideally, the first side 2 and the second side 3 are one-eighth of an inch thick though a variety of sizes could be utilized. The tab 20 located above the slot 6 is also clearly visible. The tab 20 is rotated inward at a twenty degree angle from the second side 3.

To use Deck Support, a user would secure the first side of the L-shaped bracket to the house joist using nails in the plurality of holes. The second side of the L-shaped bracket would be utilized to attach tightly the inside band of the house to the band board of the deck using the slot and a carriage bolt.

Alternatively, if blocking (additional supports to prevent joists from twisting during loading) is being used for TGI's and truss floor joists, the first side of the L-shaped bracket is attached to the house joist with carriage bolts through the square holes instead of nails through the plurality of holes.

A variety of other methods for utilizing the present invention to secure decks to homes also may be possible. In addition, the present invention may be utilized for a variety of other home or business improvement projects.

The materials utilized for Deck Support may vary widely but will likely include metal as its major component. The metals would ideally be selected from available steel or alloys of steel and aluminum. The production process related to the use of these metals insures that the metal is non-corrosive, durable and strong. The selected metal should have high impact strength and be capable of accepting and retaining coloring materials for an extended length of time.

It should be obvious that the components of the present invention can be of various shapes and sizes. It should also be obvious that the components of the invention can be made of different types of metals or other suitable materials and can be of any color.

It will be recognized by those skilled in the art that changes or modifications may be made to the above-described embodiments without departing from the broad inventive concepts of the invention. It should therefore be understood that this invention is not limited to the particular embodiments described herein, but is intended to include all changes and modifications that are within the scope and spirit of the invention as set forth in the claims. For more information go to WWW.GAPATENTS.COM or WWW.GOOGLE.COM.

Wednesday, December 16, 2009

United States Patent 7,630,299
WWW.USPTO.GOV
Magret, et al.
December 8, 2009

Retention of a stack address during primary master failover

Abstract

The present invention features embodiments of alleviating the impact to a system of stack switches, as well as to neighboring nodes communicating with such a system, when a primary master switch to secondary master switch failover occurs. The features of the present invention, generally enables a system of stack switches to retain, for a fixed or indefinite period of time, its stack address even when multiple primary master to secondary master failovers occur. This way recalculation of certain protocols--e.g., spanning trees and link aggregations--and updating of certain tables--e.g., address resolution protocol (ARP) and routing tables--are minimized.
Inventors: Magret; Vincent (Oak Park, CA), Rose; Laurence (Oak Park, CA)
Assignee: Alcatel Lucent (Paris, FR)
Appl. No.: 11/028,346
Filed: December 30, 2004

Current U.S. Class: 370/219 ; 370/220; 370/243; 370/255
Current International Class: H04J 1/16 (20060101)
Field of Search: 370/219,220,218,223,243,255
References Cited [Referenced By]
U.S. Patent Documents

6496502 December 2002 Fite et al.
6785272 August 2004 Sugihara
6801950 October 2004 O'Keeffe et al.
6934292 August 2005 Ammitzboell
7120683 October 2006 Huang
7123615 October 2006 Weyman et al.
7167441 January 2007 Donoghue et al.
7274703 September 2007 Weyman et al.
7289496 October 2007 Donoghue et al.
7305458 December 2007 Hsue et al.
7469279 December 2008 Stamler et al.
2005/0198373 September 2005 Saunderson et al.
Primary Examiner: Ngo; Ricky
Assistant Examiner: Samuel; Dewanda
Attorney, Agent or Firm: Galasso & Associates WWW.GAPATENTS.COM
Claims


We claim:

1. A switching device for coupling in a stack switch system comprising a plurality of stack switches operably coupled, the switching device comprising: two stack ports, at least one of the stack ports operably coupled with one of the plurality of stack switches; and a stack manager operable to: elect a primary master switch to perform the primary stack management functions of the stack switch system; assign a stack address to the plurality of stack switches based on a local address of the primary master; monitor for the primary master by comparing a local address of each of the plurality of stack switches with the stack address; elect a secondary master switch ready to function as a new primary master switch when the primary master fails; receive a restart time wherein the restart time is a definite fixed period or an indefinite period; determine whether the stack address is to be replaced when the primary master fails and the secondary master switch functions as the new primary master switch; replace the stack address with a new stack address based on a local address of the secondary master functioning as the new primary master switch; and replace the stack address with the new stack address, when the primary master fails and the primary master is unable to join the stack switch system within the definite fixed period restart time.

2. The switching device of claim 1, wherein the stack manager is further operable to: receive a command to replace the stack address with a new stack address; and replace, based on the received command, the stack address with the new stack address based on the local address of the secondary master functioning as the new primary master switch.

3. The switching device of claim 1, wherein the stack manager is further operable to: assign the new stack address to the plurality of stack switches.

4. The switching device of claim 1, wherein the stack manager is further operable to: elect a new secondary master to replace the secondary master switch functioning as the new primary master switch.

5. The switching device of claim 1, wherein the stack manager is further operable to: enable the primary master to join the system of stack switches; and assign the new stack address to the primary master.

6. The switching device of claim 1, wherein the stack manager is further operable to: enable one of the plurality of stack switches to join the system of stack switches as an idle switch.

7. The switching device of claim 1, wherein the stack manager is further operable to: enable one of the plurality of stack switches to join the system of stack switches as a new secondary master.

8. A method of managing a system of stack switches comprising a plurality of stack switches, one of the plurality of stack switches elected as a first primary master switch, another one of the plurality of stack switches elected as a first secondary master switch, the system of stack switches assigned a stack address, the method comprising the steps of: receiving a restart time indicating a definite restart time or an indefinite restart time; replacing the first primary master switch with the first secondary master switch to function as the second primary master, when the first primary master switch fails; electing a second secondary master from the plurality of switches when the first secondary master functions as the second primary master; replacing the stack address with a new stack address based on the local address of the secondary primary master when the restart time is a definite fixed period and the first primary master is unable to join the system of stack switches within the restart time that is definite fixed period fixed, or replacing the stack address when a command is received to replace the stack address with a new stack address; and receiving the command to replace the stack address with a new stack address.

9. The method of claim 8, the method further comprising the step of: assigning the new stack address to the plurality of stack switches.

10. The method of claim 8, the method further comprising the step of: monitoring for the primary master by comparing a local address of each of the plurality of stack switches with the stack address.

11. The method of claim 10, the method further comprising the step of: enabling the first primary master to join the system of stack switches as one of the plurality of stack switches and wherein the first primary master is assigned the stack address.

12. The method of claim 8, the method further comprising the step of: enabling one of the plurality of stack switches to join the system of stack switches as an idle switch.

13. The method of claim 8, the method further comprising the step of: enabling one of the plurality of stack switches to join the system of stack switches as a new secondary master.

14. A method of managing a system of stack switches comprising a plurality of stack switches, one of the plurality of stack switches elected as a first primary master switch, another one of the plurality of stack switches elected as a first secondary master switch, the system of stack switches assigned a stack address, the method comprising the steps of: receiving a restart time indicating a definite restart time or an indefinite restart time; replacing the first primary master switch with the first secondary master switch to function as the second primary master, when the first primary master switch fails; replacing the stack address with a new stack address based on the local address of the secondary primary master when the restart time is a definite fixed period and the first primary master is unable to join the system of stack switches within the restart time that is definite fixed period fixed, or replacing the stack address when a command is received to replace the stack address with a new stack address; and monitoring for the primary master by comparing a local address of each of the plurality of stack switches with the stack address.

15. The method of claim 14, the method further comprising the step of: receiving the command to replace the stack address with a new stack address.
Description


TECHNICAL FIELD

The invention generally relates to the management of a system of stack switches in a data communication network. In particular, the invention relates to a system of fault-tolerant stack switches adapted to detect, cope with, and recover from switch failures, without necessarily changing the stack media access control (MAC) address of the system of stack switches.

BACKGROUND

Stackable switches are switches or routers that may function in a stand-alone mode and may also function within a stack. These stackable switches, herein referred to as switches, are coupled into a single logical unit called a stack. The switches are operatively interconnected via a pair of designated stack ports present on each switch. The system of stack switches is generally coupled in series and the topology of the system generally characterized by a closed loop called a ring or an open strand of switches referred to herein as a chain. Each of the stack switches is adapted to perform switching between its own data ports as well as the data ports of other stack switches by transmitting packets via the stack ports, that facilitate the efficient transmission and switching of these packets to the appropriate stack switch port.

Each switch in a stack may be elected to become the primary master or the secondary master. The primary master performs the primary stack management functions, which may include maintaining and updating configuration file, routing information, and other stack information. The secondary master acts as a back-up to the primary master. One primary master switch and one secondary master switch are generally elected in a stack system. This election mechanism may be governed by various election criteria as known to those of ordinary skill in the art. Such election criteria, for example, are governed by the switch having the lowest media access control (MAC) address or having the longest uptime or having the lowest stack identifier. User priority may also govern the primary and secondary master election.

Various pieces of information are needed to effectively run and communicate with a system of integrated stack switches. The system of stack switches is generally, for example, identified with one Internet Protocol (IP) address and one stack address. This makes the system of stack switches appear as one logical unit, particularly, to external devices communicating with such system.

Each switch element is delivered to a customer with a unique local MAC address. This address is a globally-assigned organizationally-unique identifier that is assigned by the manufacturer. This MAC address is generally stored in persistent memory. In traditional or prior art system of stack switches, the stack address mirrors the MAC address of the currently running primary master. Thus, when a primary master fails and a secondary master starts functioning as the primary master, the stack address for the system of stack switches is also accordingly changed to reflect the MAC address of the now running primary master.

This constant change whenever a failover occurs impacts not only the system of stack switches but also surrounding devices that communicate with this stack. One example is the impact to address resolution protocol (ARP) tables and other Layer 3 tables. For example, let us assume that the system of stackable switches, Stack A, is known to surrounding devices with stack address, M1. When a failover occurs, the secondary starts functioning as the new primary master and the stack address is also accordingly changed, for example, to M2, i.e., the new primary master's MAC address. Stack A advertises its new stack address--M2. Neighboring or surrounding nodes which have already associated Stack A with stack address M1, now have to changed their ARP tables to associate Stack A with the new stack address M2. This change in stack address also entails updating and replacing all routes using the previous stack address of M1, as the next hop, with the new stack address M2.

Another aspect that may be impacted is link aggregation, in accordance with the IEEE 802.3ad Link Aggregation Standard. Link aggregation or trunking is a method of combining physical network links into a single logical link to increase bandwidth. In some prior art embodiments, changing the stack address results in the aggregates or trunks being recomputed considering that the stack address is used in computing keys necessary to provide link aggregation. A change in the stack address thus generates a new set of keys using the new address.

Another aspect that may be impacted is the recalculation of the spanning tree in accordance with the spanning tree protocol. This protocol is contained in the IEEE 802.1D standard. If the stack address is changed due to the election of a new primary master, a new spanning tree has to be recalculated to account for this change. This is particularly burdensome, when the new elected primary master becomes the new root bridge. The root bridge uses the MAC address as one of its parameters.

The change in the stack address does have a direct impact to the network and to the performance of the system of stack switches. The change of stack address gives rise to higher latency due to relearning of the new stack address or recomputation of new spanning tree or trunks. This also gives rise to situations where links are temporarily down. This impact is also particularly burdensome when multiple primary master to secondary master failovers occur. A way to alleviate this negative impact is thus highly desirable. The present invention fulfills this need.

SUMMARY

The present invention features embodiments of alleviating the impact to a system of stack switches, as well as to neighboring nodes communicating with such a system, when a primary master switch to secondary master switch failover occurs. The features of the present invention, generally enables a system of stack switches to retain, for a fixed or indefinite period of time, its stack address even when multiple primary master to secondary master failovers occur. This way recalculation of certain protocols--e.g., spanning trees and link aggregations--and updating of certain tables--e.g., address resolution protocol (ARP) and routing tables--are minimized.

In the first embodiment, the present invention provides for a switching device in a stack system comprising a plurality of stack switches operably coupled in a series and each of the plurality of stack switches having its own local address. The switching device comprises two stack ports, at least one of the stack ports operably coupled to one of the plurality of stack switch; and a stack manager. The stack manager is adapted to: elect a primary master switch to perform the primary stack management functions of the stack switch system; assign a stack address to the plurality of stack switches based on the local address of the primary master switch; elect a secondary master ready to function as a new primary master switch when the primary master switch fails; receive a restart time wherein the restart time is a definite fixed period restart time or an indefinite period of time; and determine whether the stack address is to be replaced when the secondary master switch functions as the new primary master switch. In another embodiment, the stack manager is further adapted to replace the stack address with a new stack address based on the local address of the secondary master functioning as the new primary master switch, when the primary master fails and the primary master is unable to join the stack switch system within the definite fixed period restart time.

In another embodiment, the present invention provides for a method of managing a system of stack switches comprising a plurality of stack switches, one of the plurality of stack switches elected as a first primary master switch, one of the plurality of stack switches elected as a first secondary master switch, and the system of stack switches assigned a stack address. This method comprises the steps receiving a restart time indicating a definite fixed period of time or an indefinite period of time; replacing the first primary master switch with the first secondary master switch to function as the second primary master, when the first primary master switch fails; replacing the stack address with a new stack address based on the local address of the secondary primary master only when the restart time is a definite fixed period and the first primary master is unable to join the system of stack switches within the restart time that is definite fixed period fixed, or when a command is received to replace the stack address with a new stack address.

In another embodiment, the invention provides for a switching device. This switching device may be coupled to a stack switch system comprising a plurality of stack switches operably coupled, one of the plurality of stack switches elected as a primary master to perform primary stack management functions, and another one of the plurality of stack switches elected as a secondary master to function as a new primary master when the primary master fails. The stack system is assigned a first stack address. This switching device comprises two stack ports, at least one of the stack ports adapted to operably couple with one of the plurality of stack switches; and a stack manager adapted to perform, by the secondary master functioning as the new primary master, the primary stack management functions using the first stack address and without using a local address of the new primary master.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, and in which:

FIG. 1 is a functional block diagram of a system of integrated stack switches (ISS), in accordance with the preferred embodiment of the present invention;

FIG. 2 is a functional block diagram of a stack switch employed in the ISS system, in accordance with the preferred embodiment of the present invention;

FIG. 3 is a state diagram representing the stages of a stack switch during start up, in accordance with the preferred embodiment of the present invention;

FIG. 4A is a flow chart showing the election of the primary and secondary master switches and when the secondary master functions as the new primary master, in accordance with the preferred embodiment of the present invention;

FIG. 4B is a flow chart showing high-level operations based on the restart time, in accordance with the preferred embodiment of the present invention;

FIG. 4C is a flow chart showing the operations of replacing the old stack address with a new stack address, in accordance with an embodiment of the present invention;

FIG. 5 is a flow chart showing that a joining switch element is assigned the current stack address, in accordance with an embodiment of the present invention;

FIGS. 6A, 6B, and 6C illustrate an exemplary four-element ISS system, with a predefined definite restart time, before and after the failover to the second master, and after the joining of the previous primary into the ISS, in accordance with an embodiment of the present invention;

FIGS. 7A, 7B, 7C, and 7D illustrate an exemplary four-element ISS system, with a predefined definite restart time, before and after the failover to the second master, and after the expiration of the restart time, in accordance with an embodiment of the present invention;

FIGS. 8A, 8B, 8C, and 8D illustrate an exemplary four-element ISS system, with an indefinite restart time--no restart time specified, before and after the failover to the second master, after joining of the previous primary into the ISS, and after another failure of the primary master, in accordance with an embodiment of the present invention;

FIGS. 9A, 9B, and 9C illustrate an exemplary two-element ISS system, with a predefined restart time, before and after the failover to the second master, and after the joining of the previous primary into the ISS, in accordance with an embodiment of the present invention;

FIGS. 10, 10B, and 10C illustrate an exemplary two-element ISS system, with a predefined restart time, before and after the failover to the second master and after the expiration of the restart time, in accordance with an embodiment of the present invention; and

FIGS. 11A, 11B, 11C, and 11D illustrate an exemplary two-element ISS system, with an indefinite restart time--no restart time specified, before and after the failover to the second master, after joining of the previous primary into the ISS, and after another failure of the primary master, in accordance with an embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The following detailed description illustrates the invention, by way of example not by way of limitation of the principles of the invention in a fashion that clearly enables one skilled in the art to make and use the invention, and describes several embodiments, adaptations, variations, alternatives and uses of the invention, including what is presently believed to be the best mode of carrying out the invention.

To better understand the figures, like-numbered reference numerals in various figures and descriptions are used in the following description to refer to the same or similar structures, actions, operations, or process steps. In addition, reference numerals within the one hundred series, for example, 102 and 104, are initially introduced in FIG. 1, reference numerals in the two hundred series, for example, 222 and 224, are initially introduced in FIG. 2, and so on and so forth. So, reference numerals in the nine hundred series, e.g., 920 and 940, are initially introduced in FIG. 9.

Illustrated in FIG. 1 is a functional block diagram of a system of integrated stack switches (ISS) in a data communications network. The ISS 120 includes a plurality of stack switches 100-103 operatively linked in a series to form a chain or a ring topology, for example, by means of stack links 110-113, e.g., twisted-pair or fiber optic cables. The switching devices 100-103 are preferably stackable switches operatively coupled to one another through one or more special-purpose ports referred to by those skilled in the art as stack ports. The plurality of stack switches 100-103, also referred to as stack elements and elements herein, are adapted to transmit packetized data between the other switches of the ISS 120 as well as one or more end stations and other addressable entities operatively coupled to the ISS via one or more local area networks (LANs), wide area networks (WANs), metropolitan area networks (MANs), or the Internet, for example.

In the preferred embodiment, the stack switches 100-103 are multi-layer switches adapted to perform switching and routing operations with protocol data units (PDUs), preferably frames and packets, at Layer 2 (Data Link Layer) and Layer 3 (Network Layer) as defined by the Open Systems Interconnect (OSI) reference model, although they may also perform Layers 4-7 switching operations. Each of the stack switches 100-103 is generally capable of functioning as a stand-alone network bridge, switch, or router. Together, the stack switches 100-103 cooperate to emulate a single switching device. The ISS system 120 preferably has a single stack address used by all the switch elements and a single Internet Protocol (IP) address.

With a stack manager of the preferred embodiment, the ISS 120 of the present invention, minimizes and controls the updates of tables, particularly Layers 2-3 tables, of end stations or other addressable entities operatively coupled to the ISS 120 via a network. The ISS of the present invention also minimizes and controls the computational updates needed by certain protocols, such as link aggregation and spanning tree protocol when a switch management failover occurs.

Illustrated in FIG. 2 is a functional block diagram of a stack switch employed in the ISS 120 system of the preferred embodiment. The stack switch 200 comprises one or more network interface modules (NIMs) 204, one or more switching controllers 206, a management module 220 which cooperate to receive ingress data traffic and transmit egress data traffic via each of the external ports 202. For purposes of this embodiment, data flowing into the switch 200 from another network node is referred to herein as ingress data, which comprises ingress protocol data units. In contrast, data propagating internally to a port 202 for transmission to another network node is referred to as egress data, which comprises egress PDUs. Each of the plurality of the ports 202 is preferably a duplex port adapted to receive ingress data and transmit egress data.

The NIMs 204, 204S preferably include one or more physical layer interfaces and data link layer interfaces adapted to exchange PDUs, e.g., Ethernet frames and IP packets, via network communications links (not shown). Among the plurality of ports 202 are two stack ports 202S for incorporating the particular stack switch 200 into the ISS 120. The stack port NIMs 204S associated with the two stack ports 202S are, for example, standard Ethernet ports and are adapted to exchange PDUs conventional data traffic with various compatible nodes as well as inter-stack communications to other stack switches depending on the stack configuration mode. The ingress PDUs are conveyed from the plurality of NIMs 204, 204S to the switching controller 206 by means of one or more ingress data buses 205A. Similarly, the egress PDUs are transmitted from the switching controller 206 to the plurality of NIMs 204 via one or more egress data buses 205B.

The management module 220 generally comprises a policy manager 224 for retaining and implementing traffic policies. The policies implemented by the policy manager 224 are preferably based in part on Layer 2 and or Layer 3 addressing information derived from source learning operations, route information received from other routing devices, and filtering rules uploaded by the network administrator via a configuration manager 222 using, for example, simple network management protocol (SNMP) messages 226. The traffic policies derived from source learning, other network nodes, and the administrator are made available to the routing engine 230 and collectively represented by the forwarding table 254.

The configuration manager 222 preferably is also able to receive configuration information uploaded by the network administrator. This configuration information includes restart time information, which is used to determine whether the stack address of the ISS 120 is to be replaced with a new stack address. This information may be stored in a stack information module 230, which may also contain routing and switching tables for managing the ISS. This stack information module 230 enables the various switch elements to communicate and work with each other within the stack environment.

In addition to the traffic policies, the management module 220 further includes a central management module (CMM) 210 for implementing the ISS stack switching functions discussed in more detail below. The CMM 210 of the preferred embodiment comprises a port state module 212 and a stack manager 214. The port state module 212 is adapted to monitor the operational state of the stack ports 202S using keep-alive signals, for example, and identify the presence of adjacent stack switches coupled to the stack ports 202S.

The stack manager 214 in the preferred embodiment is adapted to participate in the elections that determine the management responsibilities of each stack switch, process supervision messages used to monitor the status of the other switches, and if, necessary, serve as a primary master switch (PMS) or a secondary master switch (SMS) whose responsibilities may include assigning and propagating a stack address to one or more stack switches 100-103, and updating switching and other tables used in the switching operations of the ISS. In addition, the stack manager 214 is adapted to determine the ISS stack switch topology and process topology related messages exchanged between stack switches of the ISS 120. In particular, the stack manager 214 transmits ISS topology requests, transmits known ISS topology information to other stack switches, and maintain one or more local topology tables. In one embodiment, the stack manager 214 is also responsible for detecting the loss of an element, insertion of an additional element (causing a trap to be generated), removal of an element from the stack, determining the operational state of the associated CMM 210. The stack manager 214 is also adapted to read its own local media access control (MAC) address 218--generally assigned by the manufacture--and to receive the local MAC address of the other switch elements within the ISS. The MAC address is preferably stored in a read-only memory chip.

The switch 100 preferably comprises at least one network processor 206 capable of, but not limited to, Layer 2 (Data Link) and Layer 3 (Network) switching operations as defined in the Open Systems Interconnect (OSI) reference model. The set of possible Layer 2 protocols for operably coupling the external ports 202 to a wired and/or wireless communications link include the Institute of Electrical and Electronics Engineers (IEEE) 802.3 and IEEE 802.11 standards, while the set of possible Layer 3 protocols includes Internet Protocol (IP) version 4 defined in Internet Engineering Task Force (IETF) Request for Comment (RFC) 791 and IP version 6 defined in IETF RFC 1883.

The switching controller 206 preferably comprises a routing engine 230 and a queue manager 240. The routing engine 230 comprises a classifier 232 that receives ingress PDUs from the data bus 205A, inspects one or more fields of the PDUs, classifies the PDUs into one of a plurality of flows using a content addressable memory 233, and retrieves forwarding information from the forwarding table 254 retained in high-speed memory. The forwarding information retrieved from the forwarding table 254 preferably includes, but is not limited to, a flow identifier used to specify those forwarding operations necessary to prepare the particular PDU for egress, which may include the next-hop address and class of service (COS) or Quality of Service (QOS) provisions.

The forwarding processor 234 receives the ingress PDUs with the associated forwarding information and executes one or more forwarding operations prior to transmission to the appropriate egress port or ports. The forwarding operations preferably include but are not limited to header transformation for re-encapsulating data, VLAN tag pushing for appending one or more VLAN tags to a PDU, VLAN tag popping for removing one or more VLAN tags from a PDU, quality of service (QoS) for reserving network resources, billing and accounting for monitoring customer traffic, Multi-Protocol Label Switching (MPLS) management, authentication for selectively filtering PDUs, access control, higher-layer learning including Address Resolution Protocol (ARP) control, port mirroring for reproducing and redirecting PDUs for traffic analysis, source learning, class of service (CoS) for determining the relative priority with which PDUs are allocated switch resources, color marking used for policing and traffic shaping, and inter-stack switch labeling management used to efficiently distribute PDUs between switches 100-103 of the ISS 120, for example.

After the forwarding processor 234, the PDUs are passed to and stored in the queue manager 240 until bandwidth is available to transmit the PDUs to the appropriate egress port. In particular, the egress PDUs are buffered in one or more of a plurality of priority queues in the buffer 242 until they are transmitted by the scheduler 244 to an external port 202 via the output data bus 205B.

The switch 200 of the present invention also includes a MAC address 218. This MAC address 218 is preferably a memory chip containing the unique MAC address associated with the switch 200.

Illustrated in FIG. 3 is a state diagram representing the stages of an automatic setup mechanism employed by a stack switch of the ISS from boot-up to the fully operational modes, in accordance with a preferred embodiment of the invention. Upon initialization, a stack switch 200 enters a stackability determination state 302 in which the switch determines whether it is configured to serve as a stand-alone switch or a stack switch. The stackability is determined based on the physical and operational presence of stack ports 202S. In some embodiment of the invention, it is possible that no stack port is present in a switch. If the switch is configured to serve as a stand-alone operation 304, the stack manager 214 is disabled and the switch operates in accordance with a multi-layer switch having all data ports 202.

When configured as a stack switch, however, the port state module 212 monitors the stack links and indicates to the stack manager 214 changes of any of the two stack links. The stack manager responds, for example, to link up, e.g., a link has been inserted, or link down, e.g., a link has been removed, and accordingly performs the appropriate actions, such as to handle and process the situation wherein one or multiple elements have joined the stack, or one or multiple elements have left the stack. The stack manager 214 listens on the stack ports for keep-alive messages or other signal indicating the presence of adjacent elements. In the absence of an adjacent stack switch, the switch determines that it is a stack of one 306 and proceeds to the forwarding state 308 in which it receives and transmits data traffic on the standards data ports 202 while monitoring the stack ports 202S for the introduction of one or more additional stack elements.

If one or more switches are detected on the stack ports 202S while in the stackability determination state 302, the switch 200 proceeds to the discovery state 310 for purposes of determining the topology of the ISS 120. The stack switch 200 may then proceed to the election state 312 in which the stack switches of the ISS 120 execute a role determination process used to identify which of the elements are to serve as the primary master switch (PMS) and secondary master switch, also referred to herein as the primary master and secondary master, respectively.

The determination criteria of which of the stack elements will serve as the primary and the secondary are known to those of ordinary skill in the art. Examples of such election criteria include, but are not limited to, electing the switch element with the lowest MAC address 218 as the primary master, electing the switch element with the longest running time or uptime as the primary master, electing the primary master and the secondary master based on the slot number assigned, and electing the primary master and the secondary master based on user preference stored in a configuration file.

The primary master is responsible for ISS management functions including handling of all command line interface input and synchronizing images-i.e., synchronizing different software versions on the stack switches. This function may also include synchronizing various tables and information, e.g., switching tables, routing tables, and configuration information. The secondary master is the designated successor to the primary master and functions as the new primary master if the primary master fails or otherwise becomes non-operational. While each of the stack switches of the preferred embodiment may assume the role of the primary and secondary masters, the remaining stack switches defer to the master switches until any one of them is later elected to serve as a master.

While operating in the forwarding state 308, the switch 200 is adapted to transition into and back from the supervision state 316 and the pass-through (PT) state 320. In the supervision state 316, the element 200 transmits supervision messages to both its adjacent neighbors for supervisory purposes, analogous to a keep-alive mechanism for exchanging keep-alive messages When a new stack switch is inserted into the ISS 120 or an existing switch is removed, for example, the switch 200 automatically exchanges topology information with other stack switches and updates its stack switch neighbor tables. If both the primary and secondary masters fail at the same time, the rest of stack switches--which most likely in the forwarding state 308--proceed to election state 312 to elect a new primary master. If the secondary master fails, there is no election, but the primary master chooses one of the idle elements to take the secondary role. Once this element is chosen, the primary master advertises the new assignment to the entire stack with an election indication message that is vested with maximum authority. If the primary master fails, there is no real election, but the secondary master promotes itself to become the new primary master and chooses one of the idle elements to become the new secondary master. Once this element is chosen, the new primary master advertises the new assignment to the entire stack with an election indication message that is vested with maximum authority.

In the preferred embodiment, there is a pass-through state 320. In the pass-through (PT) state 320, the data ports 102 of the stack switch are entirely disabled and routing engine 230 configured to pass data traffic from each of its two stack ports 202S to the opposite stack port. In the PT state 320, the routing engine 320 effectively emulates a fixed wire connection between the stack ports of the two adjacent stack switch switches, thus preventing what would otherwise be a break in the continuity of the system of stack switches 120. The pass-through may be used to maintain continuity between the stack switches adjacent to a common element instead of shutting down, thereby maintaining the ISS 120 where prior art stack switch systems would have had their ring topology severed or two independent chains created. Switch elements that do not serve any primary or secondary management functions and are not pass-through switches are herein called idle switches.

As illustrated, a stack switch may transition in either direction between the discovery state 310 and the supervision state 316 since supervision is required and is enforced as early as discovery state 310 when a stack switch detects a neighbor and it should, therefore, execute supervisory tasks described in more detail below.

FIG. 4A is a high-level flowchart showing the election of the primary and secondary master switches and when the secondary master assumes the role of the primary master switch, according to an embodiment of the invention. In general, the stack manager assigns the stack address and retains such address indefinitely, unless there is a specified restart time as further discussed below.

After discovery 310 of the stack, for example, after boot-up, the stack manager 214 elects the primary master (step 400) and the secondary master (step 402). This election process may also be manually forced by the network manager, for example, via the management module 220. The stack manager 214 obtains the local MAC address 218 of the elected primary master and uses this as the stack address (step 404), which is then propagated to the other elements of the ISS system (step 406). This stack address is then stored (step 408), for example, in memory for later processing and comparison. For purposes of this illustration, this stack address is called M1. The presence or the primary master is continuously monitored (step 410) to determine if the secondary master has to take over the role of the primary master.

If the elected primary master fails (test 412), the secondary master automatically becomes the new primary master (step 414). The failure of the primary master, preferably automatically, triggers the secondary master to function as the new primary master. A new secondary master is then elected (step 416) in case the new primary master fails. A determination is then made whether to keep the current stack address or replace it with a new one. This is handled by the stack address alias module (step 418). The primary master is deemed to have failed if it generally encounters any condition that makes the primary master in a state wherein it cannot perform its primary master functions. The conditions that trigger a primary master switch to fail are known to those of ordinary skill in the art.

FIG. 4B shows the stack address alias module 418 in more detail. In the first operation, the stack manager determines what type of restart time has been defined within the ISS system 120 (step 434). Preferably, there are two types of restart time--a definite restart time and an indefinite restart time. A definite restart time is any fixed period of time, including zero second, twenty seconds, fifty minutes, thirty-six hours, four weeks, etc. The restart time has been configured into the ISS system 120, preferably, via the configuration manager 222, for example, via an SNMP message. The restart time may be specified by the network administrator or by the stack manager 214, and may also be a system default value.

The definite restart time is the allotted fixed period of time enabling the previous primary to rejoin the ISS system, before the current stack address is replaced with a new stack address mirroring the address of the new primary master. This restart time when defined, for example, may take into account temporary failover conditions--without impacting outside devices. These temporary conditions, for example, may include the primary master being offline due to accidental dislodging of cables and temporary primary master maintenance. This restart time may be of any time period, including a few seconds, hours, minutes, days, weeks, and months. Mechanisms to define an indefinite restart time and a definite restart time, including the fixed period of time, is preferably included in a network management system interfacing with the device 200 of the present invention. In one embodiment, not specifying a fixed period of time means that an indefinite restart time has been specified for the ISS system 120.

An indefinite restart time generally indicates to the stack manager that the stack address should be maintained and not changed as long as possible. In one embodiment, this may be indicated by a Boolean flag. In the preferred embodiment, the stack address is only changed when there is a command received (not shown) by the stack manager forcing it to change the stack address to the new stack address based on the local MAC address of the currently functioning primary master or when a definite restart time has been defined into the system and the primary master that recently failed is unable to join the ISS 120 within the specified definite restart time. An indefinite restart time value may be implemented in various ways. In one exemplary embodiment, a network administrator is given an option to select indefinite or definite restart time using a Boolean flag. If a definite restart time is selected, the network administrator is further enabled to enter a fixed period to indicate the definite restart time. An indefinite restart time may also be indicated by the administrator by entering, for example, a null or blank value in an input field.

If a definite restart time has been specified (test 434), a check is done to determine if the definite restart time has expired (test 432). If the restart time has not expired, the presence of the previous primary master is monitored (step 436). In the preferred embodiment, the new primary master--the previous secondary master, preferably using the stack manager, probes the presence within the ISS of a switch element 200 having a local MAC address 218 the same value as the current stack address. This current stack address was previously stored (step 408). If an element is found having a local MAC address the same as the stack address, this means that the previous primary has now rejoined the ISS system (step 440). The previous primary then rejoins the stack as an element of the ISS system (step 440) and obtains the current stack address (step 442).

The currently operating primary master is continuously monitored to determine if it has failed. This is done regardless whether a restart time is specified or not. This enables the secondary master to assume the role of the primary master and alleviate disruption when the primary master fails. If the restart time, however, has expired (test 432), the stack manager 214 executes the unmask features (step 444) of the present invention.

FIG. 4C shows the unmask features in more detail. In the first operation, the currently operating or new primary master obtains its local MAC address 218, e.g., M2 (step 452). This address, M2, is now used as the current stack address and is propagated to the rest of the elements within the ISS (step 454). This current stack address is then stored as the new current stack address (step 456). Because there is a now a change in the stack address, remote devices coupled to the ISS, for example, via a network, now have to update their respective tables, including Layer 2 and Layer 3 tables, to record the new stack address of the ISS 120. The ISS 120, if using the spanning tree protocol, may also have to recompute a new spanning tree. Link aggregation protocols may also have to be recomputed.

If an indefinite restart time has been specified (step 434) or if the primary master rejoins the ISS within the specified restart time (diagram 419 pointing back to FIG. 4A), the stack manager generally keeps using the old stack address, regardless of which element in the ISS system is the primary master or the secondary master. The stack address is maintained and not replaced, unless forced, for example, by the network administrator, through a command instructing the stack manager to replace the stack address with a new stack address or when a definite restart time has been specified and the primary master has not rejoined the ISS within the definite restart time. In other words, the features of the present invention generally maintain the old stack address and have the primary master aliases itself as another address, regardless if the primary master's local MAC address is the same or different from the stack address. By keeping the stack address stable, meaning not changing it automatically when a primary master fails, the present embodiment of the invention minimizes unnecessary updates of tables and unnecessary computations, e.g., spanning tree, and updates, e.g., ARP table updates. This is particularly helpful when the network administrator knows that the ISS configuration, particularly the elements included in that stack are generally stable and do not change over an extended period of time. This masking as a different address continues until there is a forced or automatic unmasked module. The forced unmasked module may be received by the stack manager 214 via the configuration manager 222 (not shown).

In the preferred embodiment of the invention, the ISS 120 of the present invention is also able to manually force an unmask module. This means that the stack address and the local MAC address of the current primary master element is made the same. This is helpful in those occasions wherein the network administrator decides, for example, to remove the element whose local MAC address, e.g. is M1, from the ISS--whose current stack address is also M1, and installs that element in another part of the network. Forcing the stack address and the MAC address of the primary master element to be the same avoids duplicate MAC addresses and conflicts in the network.

FIG. 5 is a high-level flowchart showing the step in accordance with the preferred embodiment of the invention when a switch element joins or rejoins the ISS 120. In the first operation, the joining, which also includes rejoining, element obtains the current stack address (step 502). The joining element is then able to transmit packets as part of the ISS. The determination of whether the joining element is assigned the primary master, the secondary master, or the idle role is dependent on stack management implementation. As known to those of ordinary skill in the art, there are many mechanisms to determine which stack management role is to be assigned to each of the elements within an ISS system 120.

FIGS. 6A, 6B, and 6C illustrate an exemplary four-element ISS system 600 with a specified definite restart time, e.g., sixty seconds. FIGS. 6A and FIG. 6B show the ISS prior to the failover and after the failover, respectively. FIG. 6C shows the ISS after the previous primary joins the stack. In this example, the ISS has four switch elements 601, 602, 603, 604. Each element has its unique local MAC address assigned by the manufacture: the first element 601 with M1 local MAC address; the second element 602 with M2 local MAC address; the third element 603 with M3 local MAC address; and the fourth element with M4 local MAC address. During the initial election, generally during system boot-up, the stack manager 214 elects a primary master and a secondary master based on the election criteria implemented in the ISS. In this exemplary embodiment, the first element 601 was elected as the primary master, while the second element 602 was elected as the secondary master. The other elements 603, 604 are assigned idle management roles. The stack manager 214 fetches the local MAC address of the primary master 601, in this example, M1, uses that address as the stack address, propagates that stack address to the rest of the switch elements within the ISS 600, and stores that as the current stack address--M1. Each element in the ISS stores, preferably in memory, the same stack address.

Referring to FIG. 6B, during operation, the primary master 601, however, failed, e.g., became off-line. This failure and failover condition may be intentional or unintentional, and may include the administrator intentionally placing the primary master off-line, the cable to the primary master being dislodged, and the power supply to the primary master being turned off. Because the primary master failed 601, the secondary master 602 automatically functions as the new primary master. The stack address--M1, however, is not changed.

FIG. 6C shows the elements of the switch after the previously failing element 601 has joined the stack 600 within the specified restart time. Because the first element rejoins the ISS 600 within the specified restart time, sixty seconds, the stack address--M1--is not changed. The joining element 601 in this exemplary embodiment is assigned to the idle management role.

FIGS. 7A, 7B, 7C, and 7D illustrate an exemplary four-element system ISS with a specified restart time, e.g., sixty seconds. FIGS. 7A and 7B are similar to FIGS. 6A and 6B, respectively. FIG. 7A and FIG. 7B show the ISS 700 prior to the failover and after the failover, respectively. FIG. 7C, however, shows the ISS 700 after the specified restart time has expired and with the previous primary not joining the ISS 700 within the restart time of sixty seconds. In this figure, the stack manager 214 obtains the local MAC address of the primary master 702, in this case M2, and uses and propagates that address as the new stack address. In this case, even if the first element 701 is removed from the ISS 700, and installed in another part of the network, there would be no duplication of the MAC address. Assuming, however, that the first element is left in the ISS 700 and is powered on and joins the stack (FIG. 7D) after a certain period of time, twenty-four hours, for example, this element 701 joins the stack in an idle management capacity and obtains the stack address, M2, similar to the other elements. A stack element that functioned previously as a stack manager thus may also join the ISS 120 of the present invention, without any changes to the stack address.

FIGS. 8A, 8B, 8C, 8C and 8D illustrate an exemplary ISS 800, but with an indefinite restart time. This means that the stack address is kept and not changed for an indefinite period of time. FIGS. 8A and FIG. 8B show the ISS 800 prior and after the failover, respectively. FIG. 8A is similar to FIGS. 6A and 7A, while FIG. 8B is similar to FIG. 6B and 7B. Considering that there is no specified restart time/indefinite restart time, the previous stack address is maintained and not changed, unless manually forced or there is a failover that warrants changing the stack address.

FIG. 8C shows the ISS 800 after the first element has joined the ISS 800. The first element is assigned to the role of an idle switch. This joining could have been done at any time after the failover. In this stage of operation, the ISS 800 still retains its stack address of M1.

Assuming that during the continuous operation of this exemplary ISS, the new primary master now fails 802. FIG. 8D shows the secondary master 803 assuming the primary master role. The fourth element 804 is elected to become the new secondary master. The stack address, even with this second primary master failure, is left unchanged and is still the same stack address even after two failovers. Thus, even multiple failovers, which would have required a multiple number of updates and computations, are now handled without requiring unnecessary calculations or updates in the part of remote devices coupled to the ISS and even by the ISS itself. The ARP tables, for example, need not be updated during the multiple failovers, because the ISS 800 is still known with the same stack address M1. The failure of the primary element is thus to some extent masked from remote devices.

FIGS. 9A, 9B, and 9C illustrate an exemplary two-element ISS 900. In general, the joining element, in a two-element ISS, is preferably assigned the secondary master role. This is done so that the joining element can back-up the primary master. So unlike FIGS. 6A, 6B, 6C where the joining element is assigned the idle role, in this two-element ISS 900, it is assigned the secondary master role.

FIGS. 9A and 9B illustrate the two-element ISS 900 with a definite restart time--e.g., twenty minutes--before and after the failover, respectively. During the first election, the first element 901 is assigned to be the primary master and the second element 902 is assigned to be the secondary master. A failover, however, occurs as shown in FIG. 9B. The secondary master 902 thus becomes the primary master.

FIG. 9C shows that the first element joins the ISS again during the specified restart time of twenty minutes. In this case, the first element 901 becomes the secondary master and is assigned the stack address of also M1. The stack address, M1, is not changed.

FIGS. 10A, 10B, and 10C illustrate the two-element ISS 1000 similar to FIGS. 9A and 9B. FIG. 10C, however, shows that the first element 1001 failed to join the ISS 1000 within the specified restart time of twenty minutes. In this case, the stack manager replaces the old stack address, M1, obtains the local MAC address of the primary master, in this case, M2, and then uses M2 as the new stack address.

FIGS. 11A, 11B, 11C, and 11D illustrate another two-element ISS 1100 but with an indefinite restart time. FIG. 11A is similar to FIGS. 9A and 10A. FIG. 11B is similar to FIGS. 9B and 10B. FIG. 11C, however, shows that the first element 1101 eventually rejoins the ISS after the failover. In this case, the first element joins as a secondary master 1101 being assigned the same stack address of M1. The primary master 1102, however, fails later on. The secondary master 1101, in FIG. 1D, assumes the primary master role. The stack address of M1 is still the same, even after multiple failovers.

The present invention has been described above in terms of a presently preferred embodiment so that an understanding of the present invention can be conveyed. There are, however, many configurations for switches, forwarding devices, and stack managers not specifically described herein but with which the present invention is applicable. The present invention should therefore not be seen as limited to the particular embodiments described herein, but rather, it should be understood that the present invention has wide applicability with respect, for example, to switches, forwarding devices, and stack managers generally. For example, a stack manager implementing a new election mechanism, for example, having an ISS with more than two management roles, may still be used within the features of the present invention.

All modifications, variations, or equivalent arrangements and implementations that are within the scope of the attached claims should therefore be considered within the scope of the invention. For more information go to WWW.GAPATENTS.COM or WWW.GOOGLE.COM.