ROUTER

This application claims priority to Indian Patent Application No. IN2174/DEL/2011, filed with the Indian Patent Office on August 1, 2011 and entitled "METHOD FOR HANDLING LINK STATE ADVERTISEMENT AND ROUTER", which is incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

This application relates to a router and a method for handling an LSA (link state advertisement) and in particular, to database exchange and process when two OSPF (open shortest path first) routers are forming a full adjacency.

BACKGROUND

OSPF is a link-state routing protocol. It is designed to be run internal to a single autonomous system. Each OSPF router maintains an identical database describing the autonomous system's topology. From this database, a routing table is calculated by constructing a shortest path tree.

OSPF uses DD-Exchange (data description exchange) to synchronize LSDB (link state database) between two routers during adjacency formation. OSPF protocol works on the basis that both routers will have their LSDBs completely synchronized after DD-Exchange. Once two routers form adjacency with each other, further changes in LSDB will be flooded using reliable flooding algorithm. OSPF uses aging mechanism to age out LSAs in LSDB. Originating router periodically refreshes its LSAs to avoid them from getting aged out.

The flaw in DD-Exchange algorithm is that the data description packet does not contain complete LSA; it just contains the header of LSA (LSA-Header). There is a chance that LSA-Headers of two LSAs will be same even though their bodies are different. This can happen when LSA-Headers exchanged in DD-Exchange are same but bodies of LSA (LSA-Body) are different. In this case peers forming adjacency will not request for such LSAs.

Because of this in some cases, after DD-Exchange, there is a chance that LSDBs of two routers are different. This is a significant problem in protocol, but this will be recovered once the LSAs are refreshed after LsRefreshlnterval (1800 Seconds).

However, the applicant found that in order to allow efficient operation indemand circuits, a mechanism which avoids periodic LSA refresh has been defined. In this case, OSPF router advertises an LSA with DoNotAge bit to indicate that neighbor not to age out the LSA if it is not refreshed. The LSA with DoNotAge bit will not be periodically refreshed by the originating router and also it will not be aged out by other routers.

[Reference 1 ] "OSPF Version 2", STD 54, RFC 2328

[Reference 2] "Extending OSPF to Support Demand Circuits", RFC 1793

SUMMARY

One aspect of the present invention pertains to a method and a router for handling an

LSA.

According to a first aspect of the present invention, there is provided a method for handling an LSA, the method comprising:

receiving, by a first router, a data description packet from a second router, wherein the data description packet includes a header of an LSA in the second router, the first router and the second router are OSPF (Open Shortest Path First) neighbors;

determining, by the first router, the first router is a requester, and there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header; and

requesting for, by the first router, a body of the LSA in the second router from the second router by sending a link state request packet.

According to one aspect of the present invention, there is provided a first router, the first router comprising: a first receiving unit, configured to receive a data description packet from a second router, wherein the data description packet includes a header of an LSA in the second router, the first router and the second router are OSPF (Open Shortest Path First) neighbors;

a first determining unit, configured to determine the first router is a requester, and to determine there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header; and

a requesting unit, configured to request for a body of the LSA in the second router from the second router by sending a link state request packet.

According to one aspect of the present invention, there is provided a computer-readable program, wherein when the program is executed in a router, the program enables the computer to carry out the method for handling an LSA.

According to one aspect of the present invention, there is provided a storage medium in which a computer-readable program is stored, wherein the computer-readable program enables the computer to carry out the method for handling an LSA.

The advantages of one aspect of the present invention exist in that the first router will get a body of an LSP in the second router when an LSP in the first router and the LSP in the second router have the same header. This could help the first router determine whether the LSP in the first router is as same as the LSP in the second router.

These and further aspects and features of the present invention will be apparent with reference to the following description and attached drawings. In the description and drawings, particular embodiments of the invention have been disclosed in detail as being indicative of some of the ways in which the principles of the invention may be employed, but it is understood that the invention is not limited correspondingly in scope. Rather, the invention includes all changes, modifications and equivalents coming within the spirit and terms of the appended claims.

Features that are described and/or illustrated with respect to one embodiment may be used in the same way or in a similar way in one or more other embodiments and/or in combination with or instead of the features of the other embodiments.

It should be emphasized that the term "comprises/comprising" when used in this specification is taken to specify the presence of stated features, integers, steps or components but does not preclude the presence or addition of one or more other features, integers, steps, components or groups thereof.

Many aspects of the invention can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present invention. To facilitate illustrating and describing some parts of the invention, corresponding portions of the drawings may be exaggerated in size, e.g., made larger in relation to other parts than in an exemplary device actually made according to the invention. Elements and features depicted in one drawing or embodiment of the invention may be combined with elements and features depicted in one or more additional drawings or embodiments. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views and may be used to designate like or similar parts in more than one embodiment.

BRIEF DESCRIPTION OF THE DRAWING

The drawings are included to provide further understanding of the present invention, which constitute a part of the specification and illustrate the preferred embodiments of the present invention, and are used for setting forth the principles of the present invention together with the description. The same element is represented with the same reference number throughout the drawings.

In the drawings:

Figure 1 is a schematic diagram of a topology of routers in the prior art.

Figure 2 is a flowchart of the method of an embodiment of the present invention.

Figure 3 is a flowchart of the method of another embodiment of the present invention. Figure 4 is a sequence diagram showing the DD-Exchange between two routers of an embodiment of the present invention. Figure 5 is a flowchart of the method of another embodiment of the present invention.

Figure 6 is a sequence diagram showing the DD-Exchange between two routers of another embodiment of the present invention.

Figure 7 is a flowchart of the method of another embodiment of the present invention.

Figure 8 is a sequence diagram showing the DD-Exchange between two routers of another embodiment of the present invention.

Figure 9 is a schematic diagram of the router of an embodiment of the present invention.

Figure 10 is a schematic diagram of the router of another embodiment of the present invention.

Figure 11 is a schematic diagram of the router of another embodiment of the present invention.

Figure 12 is a schematic diagram of the router of another embodiment of the present invention.

DETAILED DESCRIPTION

The many features and advantages of the embodiments are apparent from the detailed specification and, thus, it is intended by the appended claims to cover all such features and advantages of the embodiments that fall within the true spirit and scope thereof. Further, since numerous modifications and changes will readily occur to those skilled in the art, it is not desired to limit the inventive embodiments to the exact construction and operation illustrated and described, and accordingly all suitable modifications and equivalents may be resorted to, falling within the scope thereof.

In the present application, embodiments of the invention are described primarily in the context of a router. However, it shall be appreciated that the invention is not limited to the context of a router and may relate to any type of appropriate electronic apparatus having the function of routers.

The preferred embodiments of the present invention are described as follows in reference to the drawings.

Figure 1 is a schematic diagram of the topology of routers in the prior art. As shown in Figure 1, there are three routers: RTA, RTB and RTC. In this topology, RTB and RTC are connected via broadcast link. RTB is a DR (Data Requester) for this link. RTA is adjacent to RTB, and RTB is adjacent to RTC.

In one example, RTA has received a network LSA originated by RTB with below contents.

LS age : 10 Options : E

LS typ : 2

Link State ID : 120.1.1.2

Advertising Router : 2.2.2.2

LS sequence number : 80000001

LS checksum : 0xC6FA

length : 32

Net mask : OxffffffOO

Attached Router : 3.3.3.3

Attached Router : 2.2.2.2

Now the link between RTA and RTB goes down. Network address of RTC is changed from 120.1.1.0/24 to 120.1.1.0/16. Then RTB again becomes the DR for the network and originates a network LSA with below contents.

LS age : 10

Options : E

LS typ : 2

Link State ID : 120.1.1.2

Advertising Router : 2.2.2.2

LS sequence number : 80000001

LS checksum : 0xC6FA

length : 32

Net mask : OxffffOOOO

Attached Router : 3.3.3.3

Attached Router : 2.2.2.2

The link between RTA and RTB comes back so that RTA and RTB form adjacency again. But RTA will not request for the network LSA advertised by RTB because that RTA cannot determine that contents of LSA-Body are changed during DD according to the header of LSA.

After DD-Exchange, RTA will have a network LSA with 255.255.255.0 mask where as RTB will have a network LSA with 255.255.0.0 mask. Note that even though the network mask is changed, checksum is not changed. This is not specific to IP address used in this example. Whenever all the bits in a byte get changed, checksum will not be changed.

The embodiments of the present invention provide a method for handling an LSA. Figure 2 is a flowchart of the method of an embodiment of the present invention. As shown in Figure 2, the method comprises:

Step 201, a first router receives a data description packet from a second router, wherein the data description packet includes a header of an LSA in the second router; the first router and the second router are OSPF neighbors.

Step 202, the first router determines the first router is a requester, and determines there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header.

Step 203, the first router requests for a body of the LSA in the second router from the second router by sending a link state request packet.

Therefore, the first router will get a body of an LSP in a second router when an LSP in the first router and the LSP in the second router have the same header. This could help the first router determine whether the LSP in the first router is as same as the LSP in the second router.

In an embodiment of the present invention, a configuration parameter, RequestSameLsalnDD will be added. If this configuration is enabled, a new bit (L-Bit, LSA-Compare-By Body) will be added in the data description packet. So, if RequestSameLsalnDD is enabled, L-Bit will be set in the data description packet, and the data description packet may further comprise the identification information (L-Bit).

Furthermore, during DD-Exchange, a router will be elected as a requester (such as SameLsaRequester) as follows:

If both routers set L-Bit in the data descriprion packet, then the router elected as master in DD-Exchange will act as SameLsaRequester. Otherwise the router setting L-Bit bit will act as SameLsaRequester.

Table 1 illustrates that RequestSameLsalnDD has been configured for demand circuits. This may also be configured on other types of interfaces to ensure that LSDB is completely synchronized after adjacency formation.

In table 1, L-Bit is to indicate willingness to act as the LSA requester. Changes in DD-Packet as shown in table 1 :

Table 1

1 Version # I 2 | Packet length 1

+ - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 Router ID 1

+ - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 Area ID 1

+ - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 Checksum | AuType 1

+ - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 Authentication 1

+ - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 Authentication 1

+ - + -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 Interface MTU | Options 1 010|L|0|0|I|M|MS

+ -+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 DD sequence number 1

+ -+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

1 1

+ - - +

1 1

+- An LSA Header - + 1 1

+ - - +

1 1

+ - - +

1 1

+ -+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+

In another embodiment of the present invention, the router has been configured as the requester before step 201. There is no change in OSPF packet format. This solution is not optimal as in if both routers are configured as RequestSameLsalnDD, then both routers will request for an LSA to each other. Considering the efficiency of system, administrator must ensure that RequestSameLsalnDD is configured on only one of the two routers participating in adjacency.

Figure 3 is a flowchart of the method of another embodiment of the present invention. As shown in Figure 3, the method comprises:

Step 301, a first router receives a data description packet from a second router, wherein the data description packet includes a header of an LSA in the second router; the first router and the second router are OSPF neighbors.

Step 302, the first router determines the first router is a requester, and determines there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header.

In this embodiment, if there is not the LSA in the database of the first router, or there is the LSA in the first router but it is less recent than the LSA in the second router, then the first router may request for the body of the LSA in the second router; otherwise, not any operation may be adopted. They are described in the prior art, and we do not discuss them in the present invention.

Step 303, the first router requests for a body of the LSA in the second router from the second router by sending a link state request packet.

In this embodiment, if there is an LSA in the first router and the first router is the requester, the first router will request for the body of the LSA in the second router even though the LSA in the first router is more recent than the LSA in the second router.

In this embodiment, the LSA in the second router may be put into the link state request list, so that it can be requested in link state request packets.

As shown in Figure 3, the method further comprises:

Step 304, the first router receives the body of the LSA in the second router from the second router.

Step 305, the first router determines the body of the LSA in the second router is different from the body of the LSA in the first router.

In this embodiment, the first router may compares the body of the LSA received from the second router with the body of the LSA in the database of the first router. If they are not same, then executing step 306, otherwise finishing this process.

In this embodiment, the LSA in the second router should be removed from the link state request list after received the body of the LSA in the second router.

As shown in Figure 3, the method further comprises:

Step 306, the first router determines the LSA in the first router is originated by the first router itself.

Step 307, the first router refreshes the LSA in the first router with a next sequence number.

In this embodiment, if the LSA in the database of the first router is self-originated LSA, it means that the LSA is originated by the first router itself. Then the LSA in the first router will be refreshed with a next sequence number, and it will be treated as if the content of the LSA is changed. Figure 4 is a sequence diagram showing the DD-Exchange between two routers of an embodiment of the present invention.

As shown in Figure 4. RTB is elected as the SameLsaRequester, and the LSA in RTB is originated by RTB itself. Firstly, RTB receives a data description packet from RTA, wherein the data description packet includes a header of an LSA in RTA. Secondly, RTB requests for the body of the LSA in RTA even though there is an LSA in LSDB of RTB. Thirdly, RTB compares the body of the LSA received LSA and the body of the LSA in LSDB of RTB. Fourthly, RTB will re-orginate the LSA in RTB with a next sequence number if they are different.

Figure 5 is a flowchart of the method of another embodiment of the present invention. As shown in Figure 5, the method comprises:

Step 501, a first router receives a data description packet from a second router, wherein the data description packet includes a header of an LSA in the second router; the first router and the second router are OSPF neighbors.

Step 502, the first router determines the first router is a requester, and determines there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header.

Step 503, the first router requests for a body of the LSA in the second router from the second router by sending a link state request packet.

As shown in Figure 5, the method further comprises:

Step 504, the first router receives the body of the LSA in the second router from the second router.

Step 505, the first router determines the body of the LSA in the second router is different from the body of the LSA in the first router. As shown in Figure 5, the method further comprises:

Step 506, the first router determines the LSA in the first router is originated by the second router.

Step 507, the first router installs the LSA in the second router into the first router.

In this embodiment, if the LSA in the database of the first router is originated by the second router (the router sending LSA-update), then the received LSA in the second router is treated as a newer LSA, and it will be installed into the database of the first router.

Figure 6 is a sequence diagram showing the DD-Exchange between two routers of another embodiment of the present invention.

As shown in Figure 6. RTB is elected as the SameLsaRequester, and the LSA in RTB is originated by RTA. Firstly, RTB receives a data description packet from RTA, wherein the data description packet includes a header of an LSA in RTA. Secondly, RTB requests for the body of the LSA in RTA even though there is an LSA in LSDB of RTB. Thirdly, RTB compares the body of received LSA in RTA and the body of the LSA in LSDB of RTB. Fourthly, RTB treats the LSA in RTA as newer and installs it in LSDB of RTB if they are different. Figure 7 is a flowchart of the method of another embodiment of the present invention. As shown in Figure 7, the method comprises:

Step 701, a first router receives a data description packet from a second router, wherein the data description packet includes a header of an LSA in the second router; the first router and the second router are OSPF neighbors.

Step 702, the first router determines the first router is a requester, and determines there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header.

Step 703, the first router requests for a body of the LSA in the second router from the second router by sending a link state request packet.

As shown in Figure 7, the method further comprises:

Step 704, the first router receives the body of the LSA in the second router from the second router.

Step 705, the first router determines the body of the LSA in the second router is different from the body of the LSA in the first router.

As shown in Figure 7, the method further comprises:

Step 706, the first router determines the LSA in the first router is originated by a third router.

Step 707, the first router max-aged and flushed the LSA in the first router.

In this embodiment, the LSA in RTB will be max-aged and flushed if the LSA in RTB is neither originated by the first router nor originated by the second router. When this max-aged LSA reaches its originator, the originator will re-originate the LSA with a next sequence number.

Figure 8 is a sequence diagram showing the DD-Exchange between two routers of another embodiment of the present invention.

As shown in Figure 8. The LSA is neither self-originated nor originated by RTA, and it is originated by RTD. RTB is elected as the SameLsaRequester.

As shown in Figure 8. Firstly, RTB receives a data description packet from RTA, wherein the data description packet includes a header of an LSA in RTA. Secondly, RTB requests for the body of the LSA in RTA even though there is an LSA in LSDB of RTB. Thirdly, RTB compares the body of received LSA in RTA and the body of the LSA in LSDB of RTB. Fourthly, RTB will max-age and flush the LSA in RTB if they are different.

As shown in Figure 8. RTA may receive the max-aged LSA, and then may send the max-aged LSA. RTD may receive the max-aged LSA, and RTD will re-originate the max-aged LSA with a next sequence number, and then flood the LSA with next sequence number. RTB may receive the LSA with next sequence number, and will treat it as a newer and install it in LSDB.

It can be seen from the above embodiments that the router can request for body of the LSA from the neighbor if the router is a requester and there is an instance of the LSA in the database. The router will be refreshed and adjacent routers will not have different LSDB permanently even though the LSA is marked with DoNotAge bit in demand circuits.

The embodiments of the present invention further provide a router. The router will be called the first router in this embodiment, and there is another router called the second router. The first router and the second router are OSPF neighbors.

Figure 9 is a schematic diagram of the router of an embodiment of the present invention. As shown in Figure 9, the first router comprises: a first receiving unit 901, a first determining unit 902 and a requesting unit 903.

Wherein, the first receiving unit 901 is used to receive a data description packet from the second router, wherein the data description packet includes a header of an LSA in the second router. The first determining unit 902 is used to determine the first router is a requester, and to determine there is an LSA in the first router, wherein both the LSA in the first router and the LSA in the second router have the header. The requesting unit 903 is used to request for a body of the LSA in the second router from the second router by sending a link states request packet.

Therefore, the first router will get a body of an LSP in a second router when an LSP in the first router and the LSP in the second router have the same header. This could help the first router determine whether the LSP in the first router is as same as the LSP in the second router.

Figure 10 is a schematic diagram of the router of another embodiment of the present invention. As shown in Figure 10, the first router comprises: the first receiving unit 901, the first determining unit 902 and the requesting unit 903; they are described as in the above embodiment corresponding to Figure 9.

Furthermore, as shown in Figure 10, the first router further comprises: a second receiving unit 1001 and a second deterning unit 1002.

Wherein, the second receiving unit 1001 is used to receive the body of the LSA in the second router. The second determining unit 1002 is used to determine the body of the LSA in the second router is different from the body of the LSA in the first router.

As shown in Figure 10, the first router further comprises: a third determining unit 1003 and a refreshing unit 1004.

Wherein, the third determining unit 1003 is used to determine the LSA in the first router is originated by the first router itself. The refreshing unit 1004 is used to refresh the LSA in the database with a next sequence number.

Figure 11 is a schematic diagram of the router of another embodiment of the present invention. As shown in Figure 11, the first router comprises: the first receiving unit 901, the first determining unit 902, the requesting unit 903, the second receiving unit 1001, and the second deterning unit 1002; they are described as in the above embodiment corresponding to Firgure 9.

Furthermore, as shown in Figure 11, the first router further comprises: a fourth determining unit 1101 and an installing unit 1102.

Wherein, the fourth determining unit 1101 is used to determine the LSA in the first router is originated by the second router. The installing unit 1102 is used to install the LSA in the second router into the first router.

Figure 12 is a schematic diagram of the router of another embodiment of the present invention. As shown in Figure 12, the first router comprises: the first receiving unit 901, the first determining unit 902, the requesting unit 903, the second receiving unit 1001, and the second deterning unit 1002; they are described as in the above embodiment corresponding to Figure 9.

Furthermore, as shown in Figure 12, the first router further comprises: a fifth determining unit 1201 and a flushing unit 1202.

Wherein, the fifth determining unit 1201is used to determine the LSA in the first router is originated by a third router. The flushing unit 1202 is used to max-age and flush the LSA in the first router.

In an embodiment, the data description packet further includes identification information (such as L-Bit), the first router further comprises: a electing unit (not shown). The electing unit is used to elect the router as the requester according to the identification information.

In another embodiment, the first router further comprises: a configuring unit (not shown). The configuring unit is used to configure the first router as the requester before receiving a data description packet from the second router.

The embodiments of the present invention further provide a computer- readable program, wherein when the program is executed in a router, the program enables the computer to carry out the method for handling an LSA.

The embodiments of the present invention further provide a storage medium in which a computer-readable program is stored, wherein the computer-readable program enables the computer to carry out the method for handling an LSA.

It can be seen from the above embodiments that the router can request for body of the LSA from the neighbor if the router is a requester and there is an instance of the LSA in the database. The router will be refreshed and adjacent routers will not have different LSDB permanently even though the LSA is marked with DoNotAge bit in demand circuits.

It should be understood that each of the parts of the present invention may be implemented by hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be realized by software or firmware that is stored in the memory and executed by an appropriate instruction executing system. For example, if it is realized by hardware, it may be realized by any one of the following technologies known in the art or a combination thereof as in another embodiment: a discrete logic circuit having a logic gate circuit for realizing logic functions of data signals, application- specific integrated circuit having an appropriate combined logic gate circuit, a programmable gate array (PGA), and a field programmable gate array (FPGA), etc.

The description or blocks in the flowcharts or of any process or method in other manners may be understood as being indicative of comprising one or more modules, segments or parts for realizing the codes of executable instructions of the steps in specific logic functions or processes, and that the scope of the preferred embodiments of the present invention comprise other implementations, wherein the functions may be executed in manners different from those shown or discussed, including executing the functions according to the related functions in a substantially simultaneous manner or in a reverse order, which should be understood by those skilled in the art to which the present invention pertains.

The logic and/or steps shown in the flowcharts or described in other manners here may be, for example, understood as a sequencing list of executable instructions for realizing logic functions, which may be implemented in any computer readable medium, for use by an instruction executing system, device or apparatus (such as a system including a computer, a system including a processor, or other systems capable of extracting instructions from an instruction executing system, device or apparatus and executing the instructions), or for use in combination with the instruction executing system, device or apparatus.

The above literal description and drawings show various features of the present invention. It should be understood that those skilled in the art may prepare appropriate computer codes to carry out each of the steps and processes as described above and shown in the drawings. It should be also understood that all the terminals, computers, servers, and networks may be any type, and the computer codes may be prepared according to the disclosure to carry out the present invention by using the apparatus.

Particular embodiments of the present invention have been disclosed herein. Those skilled in the art will readily recognize that the present invention is applicable in other environments. In practice, there exist many embodiments and implementations. The appended claims are by no means intended to limit the scope of the present invention to the above particular embodiments. Furthermore, any reference to "a device to..." is an explanation of device plus function for describing elements and claims, and it is not desired that any element using no reference to "a device to..." is understood as an element of device plus function, even though the wording of "device" is included in that claim.

Although a particular preferred embodiment or embodiments have been shown and the present invention has been described, it is obvious that equivalent modifications and variants are conceivable to those skilled in the art in reading and understanding the description and drawings. Especially for various functions executed by the above elements (portions, assemblies, apparatus, and compositions, etc.), except otherwise specified, it is desirable that the terms (including the reference to "device") describing these elements correspond to any element executing particular functions of these elements (i.e. functional equivalents), even though the element is different from that executing the function of an exemplary embodiment or embodiments illustrated in the present invention with respect to structure. Furthermore, although the a particular feature of the present invention is described with respect to only one or more of the illustrated embodiments, such a feature may be combined with one or more other features of other embodiments as desired and in consideration of advantageous aspects of any given or particular application.