System and method for routing ISIS traffic through unidirectional links of a computer network

A system and method routes data traffic over a unidirectional link of a computer network configured to implement a routing protocol, such as the ISIS routing protocol. To that end, the invention extends the ISIS routing protocol to allow dynamic discovery of neighboring routers (i.e., neighbors) that are connected via the unidirectional link and subsequent establishment of an adjacency between the neighbors over the link. Adjacency establishment is illustratively effected through the use of novel type/length/value (TLV) encoded formats appended to ISIS Hello packets to convey information between the neighbors.

FIELD OF THE INVENTION

This invention relates generally to computer networks, and, more specifically, to routing traffic over unidirectional links of a computer network.

BACKGROUND OF THE INVENTION

A computer network is a geographically distributed collection of interconnected communication links for transporting data between nodes, such as computers. Many types of computer networks are available, with the types ranging from local area networks (LANs) to wide area networks (WANs). A LAN provides relatively short distance communication among the interconnected nodes, whereas a WAN enables long distance communication over links provided by public or private telecommunications facilities. The nodes typically communicate by exchanging discrete frames or packets of data according to predefined protocols. In this context, a protocol consists of a set of rules defining how the nodes interact with each other.

Computer networks may be further interconnected by an intermediate node, such as a router, to extend the effective “size” of each network. Since management of interconnect computer networks can prove burdensome, smaller groups of computer networks may be maintained as routing domains. In this context, a routing domain is broadly construed as a collection of interconnected nodes within a common address space (e.g., a level, area or autonomous system). The networks within a routing domain are typically coupled together by intradomain routers. These routers manage communication among networks within their domains and communicate with each other using an intradomain routing protocol (or interior gateway protocol, IGP). An IGP protocol, such as a conventional link-state protocol, defines the manner with which routing information and network-topology information are exchanged and processed in a routing domain.

An example of a conventional link-state protocol is the Intermediate-System-to-Intermediate-System (ISIS) protocol. The ISIS routing protocol is one of many routing protocols developed by the International Organization for Standardization (ISO) for use in the Open System Interconnection (OSI) protocol suite, as described inDraft of ISO/IEC10589:Second Edition, November 2002, which is incorporated herein by reference in its entirety. The ISIS protocol was originally developed to route in ISO Connectionless Network Protocol (CLNP) networks. A version, typically referred to as Integrated ISIS, has since been created that supports both CLNP and Internet Protocol (IP) networks. The ISIS routing protocol is described in detail in Request for Comments (RFC) 1195, entitledUse of OSI IS-IS for Routing in TCP/IP and Dual Environments, December 1990, which is incorporated herein by reference in its entirety.

Typically, a routing protocol, such as ISIS, requires that every link over which it operates is bidirectional in order to, e.g., establish adjacencies over the links. As used herein, an adjacency is a relationship formed between selected neighboring routers (or “neighbors”) for the purpose of exchanging routing information and abstracting the network topology. The neighbors are routers that have interfaces to a common communication link of the network, wherein an interface is a connection between a router and the link. Adjacencies are generally established and maintained through the use of a conventional Hello protocol. That is, two routers become neighbors when they see each other's Hello packets over the common link. Moreover, the Hello protocol ensures that communication between neighbors is bidirectional by periodically sending Hello packets over the interfaces. Thus, establishment and maintenance of adjacencies using routing protocols typically require bidirectional communication, i.e., the routers expect to send and receive traffic through the same interface.

Unidirectional links are often deployed in service provider networks that are configured to implement IGP routing protocols, such as ISIS. An example of such a unidirectional link deployment involves satellite broadcast that enables transmission of information to a plurality of “downstream” nodes. In a typical satellite broadcast, a transmitter (e.g., a satellite) is configured to transmit information in one direction to many receivers (e.g., the downstream nodes). Applications of a satellite broadcast include television, such as on-demand video streams, and radio broadcasts. However, unidirectional links allow traffic to be sent in one direction only and therefore there is no way for the routing protocol to establish adjacencies over the links. As a result, solutions are provided to make the unidirectional links “appear” bidirectional.

One solution that takes into account the use of routing protocols over unidirectional links is called Unidirectional Link Routing (UDLR), which consists of creating (for each unidirectional link) a tunnel. Broadly stated, a tunnel is a logical path through which encapsulated packets travel from a source endpoint through a network to a destination endpoint. Encapsulation is typically performed at the source endpoint of the tunnel and de-encapsulation is performed at the destination endpoint. Here, encapsulation may involve enclosing a particular packet (payload) in an additional header to form an encapsulated packet. The additional header provides routing information that enables the encapsulated packet to traverse the network.

A protocol that may be used in a tunneling implementation, such as UDLR, to encapsulate packets is the “Generic Routing Encapsulation” (GRE) protocol defined in RFC 1701, RFC 2784 and RFC 2890, each of which is available from the Internet Engineering Task Force, Network Working Group, http://www.ietf.org. The GRE protocol is typically executed by routers that form the source and destination endpoints of a GRE tunnel. According to the UDLR solution, the GRE tunnel serves as a “back channel” of a unidirectional high-capacity link and transparently emulates a single bidirectional link for unicast transmissions over the unidirectional link. UDLR intercepts packets that need to be sent on receive-only interfaces coupled to the links and sends them on the UDLR back-channel tunnels. When routers receive these packets over UDLR back-channel tunnels, UDLR makes the packets appear as if they were received on send-only interfaces.

However, one problem with the UDLR solution is scalability. Since the UDLR solution employs a unidirectional link to transmit information from a transmitting router to a receiving router in one direction and, in the opposite direction, the two routers use a GRE tunnel, a plurality of GRE tunnel interfaces, one for each unidirectional link, must be configured. That is, for every unidirectional link, a separate GRE tunnel (functioning as a back channel) is needed. This solution is undesirable because it requires associating each interface with an implementation cost that includes one or more data structures and associated processing resources. As such, the solution does not scale properly and the present invention is directed to improving scalability of a network configured to implement an IGP routing protocol over unidirectional links.

SUMMARY OF THE INVENTION

The present invention is directed to a system and method for routing traffic over a unidirectional link of a computer network that is configured to implement a routing protocol, such as the ISIS routing protocol. To that end, the invention extends the ISIS routing protocol to allow dynamic discovery of neighboring routers (i.e., neighbors) that are connected via the unidirectional link and subsequent establishment of an adjacency between the neighbors over the link. Dynamic discovery of the neighbors is illustratively effected through the use of novel type/length/value (TLV) encoded formats appended to ISIS Hello packets to convey information between the neighbors.

In addition, the present invention extends the ISIS routing protocol to allow computation of routes across the network taking into account that one or more links are “true” unidirectional links. This, in turn, enables the ISIS routing protocol to route traffic through the unidirectional links instead of requiring the appearance of “emulated” bidirectional links through the use of back-channel tunnels, as in previous solutions. By obviating the appearance of such bidirectional links (and the associated use of back-channel tunnels), the scalability of the network is advantageously improved.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

FIG. 1is a schematic block diagram of a computer network100, such as a service provider network, comprising a plurality of intermediate network nodes interconnected within a routing domain. The intermediate network nodes may comprise switches but, in the illustrative embodiment, are preferably routers200. The routers are illustratively interconnected by point-to-point communication links, such as unidirectional link102and bidirectional links104. Communication among the routers200is typically effected by exchanging discrete protocol data units or packets in accordance with predefined protocols, such as the Connectionless Network Protocol (CLNP) and/or the Transmission Control Protocol/Internet Protocol (TCP/IP). Routing decisions within the routing domain may further rely on a predetermined “interior” gateway routing protocol (IGP). An example of an IGP is a conventional link-state protocol, such as the Intermediate-System-to-Intermediate-System (ISIS) protocol. It will be understood to those skilled in the art that other protocols may be advantageously used with the present invention.

FIG. 2is a schematic block diagram of a router200that may be advantageously used in accordance with the present invention. The router200comprises a route processor202coupled to a memory204and a plurality of network interface adapters210via a bus205. The memory204may comprise storage locations addressable by the processor and interface adapters for storing software programs and data structures that may be advantageously used with the inventive technique described herein. The route processor202may comprise processing elements or logic for executing the software programs and manipulating the data structures. It will be apparent to those skilled in the art that other processor and memory means, including various computer readable media, may be used for storing and executing program instructions pertaining to the inventive technique described herein.

A router operating system220, portions of which is typically resident in memory204and executed by the route processor202, functionally organizes the router by, inter alia, invoking network operations in support of software processes executing on the router. In one embodiment of the invention, the operating system220may be implemented as a single process with a large memory address space, wherein pieces of code within that process provide operating system services, such as one or more routing protocols. Yet, in the illustrative embodiment, the operating system services may be implemented as separately-scheduled processes in distinct, protected address spaces. These software processes or modules, each with its own process address space, execute on the router to manage resources internal to the router and, in the case of the ISIS routing protocol, to interact with users.

FIG. 3is a schematic block diagram illustrating the interaction between various modules of the router in accordance with the present invention. In the illustrative embodiment, the router modules are embodied as processes, although it will be understood to those skilled in the art that the modules may be implemented as hardware, software, firmware, or any combination thereof. An interface module310is adapted to control an interface, such as unidirectional link interface320or a bidirectional link interface330, in the router200. The interface module310interacts with a routing protocol module, e.g., the ISIS protocol engine350, to inform the protocol engine as to the type of interface it controls (e.g., unidirectional link interface320) and as to which side (e.g., receive-only side or send-only side) of that interface the router is connected. A configuration module340is adapted to configure the ISIS protocol on the interfaces320and330.

In addition, the ISIS protocol engine350illustratively interacts with two conventional transmission stacks: a CLNP encapsulation transmission stack325configured to encapsulate/de-encapsulate CLNP-encapsulated packets transmitted/received over the unidirectional link interface320and an IP encapsulation transmission stack335configured to encapsulate/de-encapsulate IP-encapsulated packets transmitted/received over the bidirectional link interface330. Broadly stated, the transmission stacks325and335comprise a plurality of layers that interact to format data for transfer over the links of network100. Predetermined services are performed on the data as it passes through the layers and the layers communicate with each other by means of the predefined protocols.

The present invention is directed to a system and method for routing traffic over a unidirectional link of a computer network that is configured to implement a routing protocol, such as the ISIS routing protocol. To that end, the invention extends the ISIS routing protocol to allow dynamic discovery of neighboring routers (i.e., neighbors) that are connected via the unidirectional link and subsequent establishment of an adjacency between the neighbors over the link. Dynamic discovery of the neighbors is illustratively effected through the use of novel type/length/value (TLV) encoded formats appended to ISIS Hello packets to convey information between the neighbors.

In addition, the present invention extends the ISIS routing protocol to allow computation of routes across the network taking into account that some links are “true” unidirectional links. This, in turn, enables the ISIS routing protocol to route traffic through the unidirectional links instead of requiring the appearance of “emulated” bidirectional links through the use of back-channel tunnels, as in previous solutions. By obviating the appearance of such bidirectional links (and the associated use of back-channel tunnels), the scalability of the network is advantageously improved.

Adjacency Over Unidirectional Link

As noted, the ISIS routing protocol generally requires that every link over which it operates is bidirectional in order to, e.g., establish adjacencies over the links. An adjacency is a relationship formed between selected neighboring routers (or “neighbors”) for the purpose of exchanging routing information and abstracting the network topology.

The adjacency is generally established and maintained through the use of a conventional Hello protocol that, in the case of ISIS, ensures communication between the neighbors is bidirectional by periodically exchanging conventional ISIS Hello packets, described in the above incorporatedDraft of ISO/IEC10589:Second Edition.

The ISIS Hello packets may also be used by a router to dynamically discover neighbors coupled to its attached links. Typically, the ISIS routing protocol is configured to exchange Hello packets between directly connected routers, e.g., routers that are connected via a bidirectional link. As noted, the present invention extends the ISIS routing protocol to allow dynamic discovery of neighbors that are connected via a unidirectional link using, e.g., multi-hop Hello packets. That is, the present invention generally allows a router to send multi-hop Hello packets to a discovered neighbor to which it is not directly connected. To that end, the ISIS Hello packets traverse an alternate, multi-hop path to the neighbor (rather than through a directly-connected unidirectional link).

Assume router200ais connected to unidirectional link102as send-only router, e.g., Rtr A, and wishes to establish an adjacency with receive-only router200b, e.g., Rtr B, over unidirectional link102. The adjacency is established through the use of the conventional ISIS Hello protocol by exchanging ISIS Hello packets between the routers. To that end, the ISIS protocol engine350of Rtr A200acreates an ISIS Hello message that is encapsulated by CLNP encapsulation transmission stack325into a CLNP-encapsulated, multicast ISIS Hello packet for transmission over its unidirectional link interface320to Rtr B. Specifically, the ISIS protocol engine350of Rtr A generates a process message data structure (e.g., the ISIS Hello message) that is passed to the CLNP encapsulation transmission stack325, which transforms the message into an ISIS Hello packet by, inter alia, encapsulating a conventional CLNP header onto the message.

Because it is connected to the receive-only side of unidirectional link102, Rtr B cannot transmit a similar ISIS Hello packet over the link to Rtr A in response to receipt of the packet. Thus, according to an aspect of the invention, Rtr B returns an ISIS Hello packet over an alternate, multi-hop path110to neighbor Rtr A. The multi-hop path110comprises a plurality of bidirectional links104adapted to transfer IP-encapsulated packets between the routers. However, the conventional CLNP-encapsulated ISIS packet does not contain IP addresses (and, in particular, a source IP address of the sending router, Rtr A) needed for the ISIS Hello packet to traverse the multi-hop path110to neighbor Rtr A.

According to another aspect of the invention, the ISIS protocol engine350of Rtr A200amodifies the ISIS Hello packet through the introduction of a new type/length/value (TLV) encoded format configured to convey information to the receive-only router, Rtr B.FIG. 4is a schematic block diagram of a CLNP-encapsulated, multicast ISIS Hello packet400with an appended TLV encoded format450that may be advantageously used with the present invention. The packet400comprises a conventional CLNP header410pre-pended to a conventional ISIS Hello message420. In addition, the TLV450contains an IP address that the receive-only router Rtr B uses when sending its IP-encapsulated multi-hop ISIS Hello packets to Rtr A. That is, the scope of TLV450is to enable a send-only router Rtr A to encode a source IP address to its neighbor, i.e., a receive-only router Rtr B, to thereby enable Rtr B to use that source address as a “destination” IP address when encapsulating IP Hello packets to send back to the send-only router.

Essentially, this aspect of the invention involves an extension to the ISIS protocol that provides a TLV450for an ISIS packet. The TLV encoding format is a general way to communicate information between nodes, such as routers. The TLV450is used to identify a type (T) of information being communicated (conveyed), a length (L) of information to be conveyed and a value (V) of the actual information conveyed. The length (L) parameter contained in the length field454is typically implementation-specific and can denote the length from the beginning of the Type field452of the attribute450to the end. However, the length generally denotes the length of the Value (V) field456and not the Type (T) or Length (L) fields. Illustratively, a predetermined type (T) may be defined for the TLV450having a value (V) of a send-only source IP address458.

In response to receipt of the CLNP-encapsulated ISIS Hello packet400, the CLNP encapsulation transmission stack325of the receive-only router, Rtr B, deencapsulates the CLNP header410from the packet and passes the ISIS Hello message420with appended TLV450to the ISIS protocol engine350on Rtr B for processing. The receive-only router then proceeds with establishment of an adjacency over the unidirectional link102. According to the invention, the receive-only router is configured to locate the appended TLV450and extract the send-only source IP address458, which specifies the IP address to use when responding to the packet400in order to establish the adjacency. In particular, ISIS protocol engine350on the receive-only router is configured to extract the send-only source IP address458from the TLV450.

The ISIS protocol engine350then cooperates with the IP encapsulation transmission stack335of Rtr B to create an IP-encapsulated unicast ISIS Hello packet for transmission to Rtr A. More specifically, the ISIS protocol engine350of Rtr B generates a process message data structure (e.g., the ISIS Hello message) that is passed to the IP encapsulation transmission stack335, which transforms the message into an ISIS Hello packet by, inter alia, encapsulating a conventional IP header onto message.FIG. 5is a schematic block diagram of an IP-encapsulated, unicast ISIS Hello packet500that may be advantageously used with the present invention. The packet500comprises a conventional IP header510pre-pended to a conventional ISIS Hello message520. Notably, the IP header510includes a source IP address512equal to receive-only unidirectional interface address514(e.g., of Rtr B) and a destination IP address516equal to send-only source IP address458(e.g., of Rtr A) extracted from TLV450. The IP-encapsulated unicast ISIS Hello packet500is then transmitted over the bidirectional link interface330of Rtr B and onto the multi-hop path110of network100. For example, the multi-hop unicast Hello packet traverses a return path encompassing Rtr D and Rtr C, where it is received by Rtr A.

According to yet another aspect of the invention, the send-only router, Rtr A, correlates the received IP-encapsulated multi-hop unicast Hello packet500with unidirectional link102. That is, notwithstanding the multi-hop path110traversed by the Hello packet500, Rtr A is configured to determine that the packet belongs to an adjacency being established between Rtr A and Rtr B by, e.g., examining the source and destination IP addresses contained in the packet500. As noted, the Hello packet500is encapsulated with a source IP address512that belongs to the unidirectional link subnet, e.g., 192.168.10/24, and a destination IP address516that was previously advertised by the receive-only router, Rtr B. Accordingly, Rtr A determines that the source IP address512belongs to directly connected unidirectional link102which, in turn, belongs to the unidirectional link subnet and that the destination IP address516is the send-only source IP address458it previously advertised to its neighbor (via TLV450). In essence, this aspect of the invention extends the functionality of the ISIS protocol engine350on the send-only router to recognize and act upon this information.

In alternate embodiments, the user (administrator) that configures the send-only router may be given the option to choose an address to advertise during adjacency establishment. Assume the send-only router has interfaces to a plurality of (many) unidirectional links within the same subnet. Over each unidirectional link, the administrator may choose to advertise an ISIS Hello packet with the new TLV encoded to a different source IP address for use by a neighbor (the receive-only router) when returning a unicast Hello packet. This is particularly advantageous in that it allows the administrator to discriminate among the different returned Hello packets, e.g., understand from which neighbor a packet was returned.

Upon correlating the received Hello packet500with unidirectional link102and, more specifically, neighbor Rtr B, Rtr A and Rtr B establish an adjacency. Since the routing protocol is ISIS, conventional ISIS adjacency state machinery is used to establish the ISIS adjacency. Thus, the ISIS protocol engines350of the send-only and receive-only routers coupled to unidirectional link102may establish an adjacency over that unidirectional link even if their Hello packets400and500did not traverse exactly the same paths.

FIG. 6is a flowchart illustrating a procedure600for establishing an adjacency over a unidirectional link of a computer network that is configured to implement a routing protocol, such as the ISIS routing protocol, in accordance with the present invention. The procedure starts at Step605and proceeds to Step610where send-only router, Rtr A, creates a CLNP-encapsulated, multicast ISIS Hello packet with a TLV configured to convey a send-only source IP address for use by receive-only router, Rtr B. In Step615, the send-only router transmits the CLNP-encapsulated Hello packet over the unidirectional link to the receive-only router. In Step620, the receive-only router extracts the send-only source IP address from the TLV of the packet and, in Step625, uses that address as destination IP address when creating an IP-encapsulated unicast ISIS Hello packet. In Step630, the receive-only router transmits the IP-encapsulated Hello packet over a multi-hop path of the network to the send-only router. In Step635, the send-only router correlates the IP-encapsulated Hello packet with the unidirectional link and, in Step640, establishes an adjacency with the receive-only router over the unidirectional link. The procedure then ends at Step645.

Forwarding MAC Addresses

Once the adjacency is established, the send-only router is generally ready to forward data packets over the unidirectional link102. Data forwarding, in this context, denotes forwarding of actual data packets and not ISIS routing protocol packets. In the case of point-to-point links, cables or fibers, media access control (MAC) addresses are not typically needed because the data packets are merely forwarded over one end of the link (wire) and are received by the router at the other end of the wire. However, in the case of a satellite link, the identity of the receiver is needed, particularly for unicast transmission of data packets to the receiver.

Thus, in order to forward such data traffic, the send-only router needs to know the MAC address of each of its neighbors. Moreover, since data forwarding occurs in only one direction over the unidirectional link, this aspect of the invention concerns only the send-only router forwarding data to the receive-only router. In the case of unidirectional links, the conventional address resolution protocol (ARP) does not work; accordingly, another aspect of the present invention contemplates use the IP-encapsulated, unicast ISIS Hello packet described above to propagate MAC addresses from the receive-only router to the send-only router.

FIG. 7is a schematic block diagram of an embodiment of IP-encapsulated, unicast ISIS Hello packet700with an appended TLV encoded format that may be advantageously used with the present invention. The packet700comprises the IP header510and ISIS Hello message520of the IP-encapsulated unicast Hello packet500(FIG. 5) with a TLV750that is appended by the receive-only router, Rtr B, prior to returning the packet to the send-only router, Rtr A. Notably, the TLV750conveys the identity of the receive-only router to the send-only router. To that end, the TLV750contains the MAC address that the send-only router uses when forwarding (routing) traffic over the unidirectional link102to the receive-only router. According to the invention, a predetermined type (stored in type field752) may be defined for the TLV750with a length (stored in length field754) determined by the length of value field756, which is encoded with the MAC address of the unidirectional link interface on the receive-only router758. The IP-encapsulated unicast ISIS Hello packet700is thereafter transmitted over the bidirectional link interface330of Rtr B and onto the multi-hop path110of network100, as described above.

Shortest Path First (SPF) Algorithm Computation.

Once the adjacency is established and the MAC address to use is known, the receive-only router is ready to compute the multi-hop path to the send-only router. Here, it is important that the receive-only router never consider sending a packet into the unidirectional link (because that router is on the wrong side of the link). Thus, the receive (RX)->transmit (TX) direction of the unidirectional link102should never be incorporated in any router topology and the router is instructed that the RX->TX direction of the unidirectional link (from receiver to sender) should never be used. Illustratively, this instruction is manifested as an infinite metric definition in RFC 3784 entitledIntermediate-System-to-Intermediate-System(IS-IS)Extensions for Traffic Engineering(TE) dated June 2004, which is hereby incorporated by reference in its entirety.

Specifically, the RX->TX direction of the unidirectional link is not part of any Shortest Path Tree in any router if configured with maximum_link_metric, as specified in RFC 3784. That is, the concept of an infinite metric (max metric) as defined in ISIS states that, if advertised with the maximum link metric (2^24-1), a link must not be considered during normal SPF computation. Thus, configuring a link with a metric that is infinite, e.g., all 24 bits of the metric set to 1, ensures that every ISIS router in the domain/area that computes SPF will never use that link. In other words, the RX->TX direction of a particular unidirectional link (or route) is advertised throughout the domain/area with an infinite metric. Thereafter when an SPF computation is performed on the contents of an ISIS routing table, the link (or route) having an infinite metric is not considered in the computation.

Next-hop calculation does not differ from the calculation used in conventional bidirectional links. The receive-only router never uses the unidirectional link interface as a next-hop interface so there is no specific next-hop calculation. The next-hop calculation performed by the send-only router takes into consideration that the receive-only router/neighbor is reachable through the unidirectional link and with a MAC address advertised within the Hello packets originated by the receive-only router. The send-only router thus has all the information needed to correctly populate the next-hop attributes of any route whose next-hop is the receive-only router.

While there has been shown and described an embodiment of a system and method for routing traffic over unidirectional links of a computer network that is configured to implement a routing protocol, such as the ISIS routing protocol, it is to be understood that various other adaptations and modifications may be made within the spirit and scope of the present invention. For example, it should be noted that the novel TLVs450and750(used for adjacency establishment and data forwarding, respectively) do not need to be included on every ISIS Hello packet (sent by the send-only router and the receive-only router, respectively) since all that is required is that the information be communicated once. However, in the illustrative embodiment, the new TLVs450and750are included on every Hello packet transmission. This obviates additional processing and complexity that would be required when advertising this information only once; in other words, this obviates the need to ensure that information was received (i) initially, (ii) in response to a configuration change, and (iii) if removed. It is thus more efficient to send the TLV each time the Hello packet is sent.

The foregoing description has been directed to specific embodiments of this invention. It will be apparent, however, that other variations and modifications may be made to the described embodiments, with the attainment of some or all of their advantages. For instance, it is expressly contemplated that the teachings of this invention, including the various modules and stacks described herein, can be implemented as software, including a computer-readable medium having program instructions executing on a computer, hardware, firmware, or a combination thereof. In addition, it is understood that the data structures, such as packets and TLVs, described herein can include additional information while remaining within the scope of the present invention. Accordingly this description is to be taken only by way of example and not to otherwise limit the scope of the invention. Therefore, it is the object of the appended claims to cover all such variations and modifications as come within the true spirit and scope of the invention.