Software-defined networking (SDN) is an approach to networking in which control is decoupled from hardware and given to a software application, referred to herein as a SDN controller. Conventionally, when a packet arrives at a network device in a typical network, the control plane, which is based on the switch's proprietary firmware, tells the device where to forward the packet. In some network devices, the control plane may be configured to recognize different types of packets and treat them differently, such as forwarding the packets to different network devices or dropping the packets if certain criteria are met.
In a SDN enabled network, a network administrator can change how the network devices route data packets using the software application without having to, for example, send a technician to the individual network devices. The administrator can remotely reconfigure the rules in the control plane of the network devices—e.g., prioritizing, de-prioritizing or even blocking specific types of packets—using the SDN controller. A SDN enabled network may allow the administrator to manage traffic loads in a flexible and more efficient manner relative to conventional network devices that use control planes based on firmware.
Moreover, SDN allows a network administrator to configure a switching fabric across multi-vendor hardware and different proprietary firmware. One standard that permits a network administrator to remotely configure and control the control plane of network devices is the OpenFlow® standard (OpenFlow is a trademark of the Open Networking Foundation). Generally, OpenFlow lets network administrators control routing tables for a plurality of network devices using a single SDN controller.
To facilitate understanding, identical reference numerals have been used, where possible, to designate identical elements that are common to the figures. It is contemplated that elements disclosed in one embodiment may be beneficially utilized on other embodiments without specific recitation.
Description
Overview
Embodiments described herein include a method, a system and a computer program product for selecting a tag for use in a SDN environment. The method, system, and computer program product receive an attribute from a user application executing on a computing device, the attribute describing a network flow associated with the user application. The method, system, and computer program product comparing the attribute to one or more rules to select at least one tag for the network flow, where the selected tag is associated with a corresponding action to be performed in the SDN environment. The method, system, and computer program product insert the received tag into at least one packet in the network flow. After inserting the selected tag, the method, system, and computer program product transmit the at least one packet into the SDN environment, where at least one network device in the SDN environment is configured to recognize the tag in the at least one packet and perform the corresponding action.
Description of Example Embodiments
Software-defined networking (SDN), in general, provides additional flexibility and solidarity relative to conventional networks. Using an SDN controller, which may be either centrally located or located on the respective network devices, a network administrator can configure the control plane and dictate how the network device routes data. For example, the network administrator may assign criteria or rules that, when satisfied, instruct the network device to perform a specific action on the received packet—e.g., drop the packet, forward the packet to a particular network device, evaluate the packet using an application on the network device, and the like. In one embodiment, the SDN controller configures the routing table or forwarding table (i.e., forwarding information base) in a network device based on the network administrator's preferences.
After the packet has been generated by the user application, a network device in the SDN enabled network may evaluate the packet to determine what action to take. The network devices may rely on the different headers of the packet—e.g., source and destination addresses, security group tag, MAC-layer priority value, VLAN ID, etc.—to determine the action. Alternatively or additionally, the network device may perform a deep packet inspection to determine what action is appropriate. In one embodiment, the network administrator may prefer that the network devices only have to evaluate the packet headers or other superficial information to identify the action to perform which may require less time than a deep packet inspection. However, the headers may not be able to convey information to the network device that is useful when determining the action to perform such as the duration of the flow, the amount of data that will be transferred in the flow, certain contractual requirements related to the flow, and the like. Moreover, in some instances, even performing a deep packet inspection may not reveal the desired action. For example, if the network administrator guaranteed that a certain network flow generated by a user application will be routed on the least-latency path through the network, evaluating the headers or performing a deep packet inspection on the packet may not reveal the source application, and thus, the network device may not be able to identify the packets that should be routed along the least-latency path.
Instead, the user application may provide a hint which may be used by a tag controller to identify a tag that is inserted into the packets generated by the user application. In one embodiment, when the user application is executed on a computer device, the application transmits information (i.e., a hint) about its associated network flow via a stack associated with the computing device. One of the layers of the stack—e.g., the operating system or a virtual machine in the computing device—may be communicatively coupled to the tag controller. This layer may receive from the tag controller a hint database that includes information for selecting a tag based on a hint received from the user application. For example, the hint may identify the user application as a high-speed trading application that requires the path through the network with the least latency. Using the hint database, the layer may tag each packet generated by the trading application to a particular VLAN. Using an SDN controller, the network administrator may configure each network device such that the packets with the assigned VLAN tag traverse the network using the least latency path. In this manner, the network administrator uses the hint provided by the user application to select a tag which may be inserted into the packet which the network devices can easily evaluate to identify the appropriate action.
Because the tag controller provides the hint database to one of the layers in the stack, the network administrator may not need to directly monitor the user application. Instead, the layers in the stack may select the appropriate tag using the hint database and insert the tag into the network flow. Similarly, the programmer who developed the user application may not need to have knowledge about the underlying layout of the SDN enabled network. Instead, the programmer of the user application may provide a description of the hints to the network administrator which may then load the hint database onto the tag controller. The controller may then provide the database to one of the layers in the stack. Thus, the hint and the hint database are an indirect communication method by which the stack can select the appropriate tag for the network traffic that suits the configuration of the particular network.
FIG. 1 illustrates a system 100 for using information provided by a network traffic application to generate a tag for a SDN enabled network. System 100 includes a tag controller 105, a computing device 110 that hosts a network traffic application 120 (e.g., a user application), a SDN controller 125, an edge device 130, and a SDN enabled network 135. The tag controller 105 may be an application executing on a computing device separate from the computing device 110 (e.g., a server connected to network 135). In one embodiment, the tag controller 105 may be accessible to a network administrator of network 135 while the network traffic application 120 is not. Accordingly, to aid the administrator and tag controller 105 when selecting an appropriate tag for the network flow (or flows) generated by the network traffic application 120, the tag controller 105 may transmit a hint database (not shown) to computing device 110 via the communication path 140. The user application 120 may provide information about the network flow—i.e., a hint—which the computing compares to the hint database to select the appropriate tag. In another embodiment, the computing device 110 may use communication path 140 to transmit the hint to tag controller 105. In this scenario, tag controller 105 may select the appropriate tag and transmit the tag back to computing device 110. The hint may define the duration of the network flow, the number of bytes likely to be transferred by the network flow, a description of the end points of the flow, an identity of the network traffic application 120, contractual obligations associated with the flow, and the like. In one embodiment, the network traffic application 120 may provide the hint before application 120 begins to generate network traffic—e.g., application 120 provides the hint when it is first executed in the computing device 110. Network traffic application 120 may provide a hint based on other predefined events, such as opening a remote connection, estimating a duration of a network flow or the amount of data a network flow will carry, receiving a query or request for data, and the like.
Communication path 140 may be any communication channel used to couple the computing device to the tag controller 105. For example, communication path 140 may include edge device 130 and network 135 which route the hint from the computing device 110 to the tag controller 105. Alternatively, computing device 110 may have a separate communication link that permits device 110 to directly receive the hint database from the tag controller 105.
Computing device 110 may be any computing structure such as a server, personal computer, database, and the like that uses on a processor 115 to execute one or more applications. Processor 115 represents any processor capable of performing the task discussed herein and may include multiple processors or processors with multiple cores. When executed by processor 115, the network traffic application 120 generates one or more network flows that traverse edge device 130 and the SDN enabled network 135 to one or more end points (not shown). That is, the network traffic application may be loaded into a memory associated with the computing device 110. Network traffic application 120 may be any type of user application, such as a web server application, database application, remote-storage application (e.g., cloud storage application), and the like.
As shown, computing device 110 is coupled to edge device 130 (e.g., a switch, router, bridge, or other network device) that provides access to network 135. The SDN enabled network 135 may include a plurality of network devices that route the network flow to one or more end points. In one embodiment, the SDN enabled network 135 includes network devices whose control planes are configurable by the SDN controller 125. Specifically, the network administrator may reconfigure the rules of the control planes using the SDN controller 125 in order to prioritize, de-prioritize or block specific types of packets.
In one embodiment, the SDN enabled network 135 may represent only the network devices whose control planes are configurable by the SDN controller 125. That is, network 135 may be connected to other network devices that are controlled by a different SDN application or network devices that are not SDN enabled. For example network 135 may be only a portion of a larger network, e.g., the Internet. In these scenarios, the network administrator may have permission to access and configure only a subset of the network devices used to transmit the network flow.
As shown, tag controller 105 and SDN controller 125 may be communicatively linked via path 145. Like path 140, communication path 145 may use the SDN enabled network 135 to transmit data between the controllers 105 and 125. Alternatively, controllers 105 and 125 may be applications executing on the same computing device. Generally, communication path 145 permits the controllers 105 and 125 to share information about network 135. For example, SDN controller 125 may provide information to the tag controller 105 about the particular configuration of the network 135. Based on this information, the tag controller 105 may update the hint database such that the hints provided by application 120 are matched to tags customized to the configuration of the SDN enabled network 135. In one embodiment, the SDN controller 125 and the SDN enabled network 135 may follow the OpenFlow® standard for configuring the rules used to route data in network 135.
FIG. 2 illustrates a method 200 for generating a tag for a SDN enabled network using information about a network traffic application. At block 205, the network traffic application generates information about a network flow (i.e., a hint). The hint may be either a standalone data chunk or be embedded within another data message or communication. In one embodiment, the hint may be separate from the network flow. For example, the hint may be transmitted from the network traffic application to an operating system executing on the host computing device as part of loading the network traffic application into memory.
At block 210, the computing device selects a tag based on the hint issued by the network traffic application. For example, the operating system on the computing device may have a hint database that includes a plurality of rules that use the hint as an input to select the appropriate tag. Moreover, in one embodiment the computing device may also consider information in the packets when selecting the tag. An example rule could be if TCP flow is to port 80 (which is gathered by evaluating packets of the network flow) and transfer size is less than five megabytes (which may be information gathered from the hint) then the appropriate tag is a MPLS label value of 2459. The different manner by which the hint may be transmitted from the network traffic application to the tag controller and how the hint database is transmitted from the tag controller to the computer device will be discussed in further detail below. Once the hint is received, the computing device evaluates the hint using the hint database to determine the appropriate tag for the network flow or flows associated with the hint. As mentioned previously, the hint may define the duration of the network flow, the number of bytes likely to be transferred by the network flow, a description of the end points of the flow, an identity of the network traffic application, contractual obligations associated with the flow, and the like. In one embodiment, the network traffic application may transmit the hint before generating any network traffic on the network flow. Alternatively, the network traffic application may provide the hint after starting to transmit packets in a network flow on the SDN enabled network.
In one embodiment, the computing device may transmit the hint to the tag controller. Using the tag controller, the network administrator may select the appropriate tag for a network flow. For example, the hint database may not include an appropriate tag for a received hint. Instead of not selecting a tag, the computing device may transmit the hint to the tag controller. The administrator may use a display screen communicatively linked to the tag controller to view the hint received from the network traffic application 120. For example, the hint may inform the network administrator that the network flow transmits high-priority information that needs to traverse the network quickly. In response, the network administrator may select a tag that assigns the packets in the network flow a high-priority. In this manner, the tag controller may select a tag using input from the network administrator. Moreover, the network administrator may then use the SDN controller to configure the SDN enabled network to route packets with the selected tag through the least-latency path.
In one embodiment, the network traffic application may generate a plurality of different network flows. Each of these network flows may be associated with a different hint and/or tag. In one embodiment, the network traffic application may provide a hint associated with each of the flows, and at block 210, the computing device may evaluate each of the hints independently and select a tag for each of the flows. The selected tags may be the same or different. For example, the network traffic application may generate two different network flows: one flow is dedicated to transmitting confidential data while the other flow is associated with data that is time sensitive. The computing device may assign two separate tags to the flows such that first flow uses a firewall when traversing the network while the second flow uses the least-latency path through the network. In another embodiment, the network traffic application may provide only one hint even if the application generates a plurality of different flows. Nonetheless, the computing device may use the single hint to issue multiple tags. For example, if the hint identifies the network traffic application as a web server, the hint database in the computing device may be preconfigured with multiple rules that consider attributes of the network flows (e.g., which ports the flows use). Using the rules, the computing device may select a tag for each of the network flows from the web server.
At block 215, the computing device or the network traffic application may insert the selected tag into the network flow. For example, the computing device or network traffic application may selectively insert the tag into only certain packets in the network flow or insert the tag into all the packets in the flow. Generally, the tag may be any value that, when inserted into a packet, is easily identifiable by a network device—i.e., a value that is found without performing a deep packet inspection. In one embodiment, the tag is inserted into a packet header. In this scenario, the tag may be a predefined value that allows a network device to distinguish the packet, and thus the network flow, from other packets and network flows. For example, the tag may be a particular value for a packet's multiprotocol label switching (MPLS) header, a security group tag, a service insertion tag, a differentiated services code point (DSCP) value, VLAN ID, and the like. As will be discussed below, the tag may be inserted into the packets of the network flow by different elements in the computing device—e.g., the tags may be inserted by the network traffic application, the operating system, or a virtual machine executing on the computing device.
At block 220, the network administrator may configure the SDN enabled network to perform an action based on identifying the tag in a packet received at a network device. Stated differently, the tag may cause a network device to perform a certain action. This action may include routing the packet to a particular network device, processing the packet using an application executing on the network device, manipulating the packet, discarding the packet, and the like. In one embodiment, the network device may include a table (e.g., a flow table) that matches the tag with the action the network device should perform. In one embodiment, the network device may remove the tag from the packet before forwarding the packet to a different network device.
In one embodiment, the network administrator may configure the network in response to the tag assigned to the network flow. For example, if the hint indicates that the network flow should pass through a firewall when traversing the SDN enabled network, the computing device may assign a tag that routes the packets of the network flow through a network device hosting the firewall. In turn, the network administrator may use a SDN controller to access the edge device connected to the computer device hosting the network traffic application. Specifically, the network administrator may change or update the routing rules (or control plane) of the edge device such that packets containing the tag are routed to the network device hosting the firewall. As the network traffic application begins to generate packets, the tags are inserted into the packets which are detected by the edge device. This device then routes the packets through the firewall. Thus, in this example, the network administrator may configure the SDN enabled network after receiving the hint from the user application—e.g., the network traffic application.
In another embodiment, the tag controller or the network administrator may generate the hint database based on the current configuration of the SDN enabled network. For example, the network may have been previously configured (i.e., before the hint was transmitted at block 210) such that all data packets assigned to a particular VLAN will use the least-latency data path to traverse the network. Based on this knowledge, the tag controller may put a rule in the hint database indicated that the network flow should be assigned the particular VLAN ID associated with the least-latency data path. Accordingly, in this example, the configuration of the SDN enabled network is considered before assigning the tag to the network flow or receiving the hint from the network traffic application. Furthermore, the network administrator may not reconfigure the SDN enabled network based on the received hint, but instead uses the current configuration of the network to select the appropriate tag for the network flow.
Regardless of whether the network administrator changes the network configuration after the application begins to transmit hints or not, the configuration of the network may nonetheless be used to suit the needs of the particular user application without the application's developer having any knowledge of the configuration of the network. Accordingly, the network traffic application does not need to be customized for a particular network configuration. Instead, by transmitting the hint, any SDN enabled network may provide a customized tag that causes the underlying network devices to perform an action corresponding to the particular configuration of the network.
Although method 200 discusses selecting a tag based on a hint associated with a particular network flow (e.g., a plurality of related data packets), the present disclosure is not limited to such. For example, in other embodiments, the computer device may select a tag on a per-packet basis. That is, the network traffic application may transmit a hint which the computer device uses to identify a tag for each packet individually.
FIG. 3 illustrates a system 300 for using information about a network application to generate a SDN tag using a hierarchical stack. Specifically, system 300 includes one or more computing devices 110 that may host one or more virtual machines 305. In one embodiment, virtual machine 305 emulates the computer architecture and functions of a physical computing device. That is, virtual machine 305 may be a software implementation of a computing device that executes programs and applications like a physical machine. In this manner, the hardware resources of the computing device 110 may be divided into a plurality of virtual machines 305. Each virtual machine 305 may include one or more instantiations of an operating system 310 which may be used to execute the network traffic application 120. Operating system 310 may be any operating system capable of performing the functions described herein.
Network traffic application 120 includes a network library 320 which may contain the library routines for the application 120. In one embodiment, the network library 320 may be a sockets library. When the network traffic application 120 first is loaded into memory, opens a disk file, opens a remote connection, or registers to accept incoming connections, the application 120 may supply a chunk of data (i.e., the hint) to another element in the computing device 110. As mentioned previously, the hint may be a connection type, an estimated length of connection in both total data transfer and time, a characterization of the bandwidth required, and an indication of the reliability of these estimates. For example, when opening a TCP connection, the hint may be transmitted to the network library 320 which then passes the hint to operating system 310, but when opening a disk file, the hint may provided directly to operating system 310, thereby skipping network library 320.
The other elements shown in FIG. 3—e.g., controllers 105 and 125, network 135, and edge device 130—may perform a similar function as that described in FIG. 1. However, in one embodiment, edge device 130 may be virtualized and hosted within computing device 110.
FIG. 4 illustrates a system 400 that uses information about the network application to generate a SDN tag. Specifically, system 400 includes a stack 405 through which the network flow and the hint generated by the network traffic application 120 may traverse. Specifically, arrow 410 illustrates the path the hint may travel in stack 405 while arrow 415 illustrates the flow of network traffic from the application 120 to the SDN enabled network 135.
Dotted lines 420A-C illustrate possible communication links between the different layers in stack 405 and the tag controller 105. In one embodiment, at least one of the layers of stack 405 is communicatively coupled to the tag controller 105. For example, the operating system 310 may be configured to communicate with the tag controller 105 (i.e., path 420B is used) while the network library 320 and the virtual machine 305 are not. However, in other embodiments multiple layers of stack 405 may be communicatively coupled to tag controller 105 via lines 420A-C. Although lines 420A-C are illustrated as being separate from network 135, in one embodiment, the network library 320, operating system 310, or virtual machine 305 may communicate with tag controller 105 via the network 135. That is, the layer of stack 405 that is configured to communicate with the tag controller 105 may receive the hint database from the controller 105 through the SDN enabled network 135 and edge device 130. Alternatively, the computing device may provide a separate communication link for transmitting the hint database from tag controller 105 one of the layers in stack 405.
In one embodiment, the hint may be a data chunk ranging from, for example, one or more bits to twenty bytes of information. In one embodiment, the hint may be transmitted using I/O control in the virtual machine 305. The hint may be embedded into other data communications transferred between the layers in stack 405. For example, when detecting a remote connection, the application 120 may embed the hint in the I/O control data that flows between the different layers of stack 405. Even if one of the layers is not configured to process the hint (i.e., the layer does not have a hint database), the layer may pass the embedded hint to a lower layer which does have the hint database. For example, assuming that the operating system 310 is not configured to communicate with the tag controller 105 to receive the hint database but the virtual machine 305 is, once the operating system 310 receives the hint, the operating system 310 may simply pass the hint to the lower layer—i.e., the virtual machine 305—which recognizes the hint and selects the appropriate tag using the database. In this manner, the different layers of stack 405 do not need to be configured to recognize or process the hint.
Although path 410 illustrates that the hint traverses through the network library 320, operating system 310, and virtual machine 305, this is not a requirement—i.e., the hint may pass through only one or two of the layers. For example, if the network library 320 is configured to process the hint, then the hint may not need to be passed on to the lower levels of stack 405. If the hint is embedded in other data communication (e.g., I/O control), then the hint may “piggy-back” on that data until the hint reaches the layer with a hint database. That layer may, if desired, remove the hint from the carrier data communication before passing the data to a lower level. Thus, in one embodiment, the hint may traverse stack 405 until the hint reaches the layer that selects the tag.
Moreover, the hint may skip over one or more of the layers 405 when traversing the stack 405. For example, in some instances (e.g., when opening a disk file), the application 120 may provide the hint directly to operating system 310 and skip network library 320.
System 400 also illustrates that a network administrator 425 may influence which tag is selected as well as configure the network 135 using SDN controller 125. As mentioned previously, the network administrator 425 may use tag controller 105 to select a particular tag or re-configure the control planes of the network devices in network 135 to perform a certain action when detecting the tag in a packet. However, in other embodiments, the techniques discussed herein may be performed without any input from the network administrator 425.
FIG. 5 illustrates a method 500 for using information about a network application to generate a SDN tag using a hierarchical stack. At block 505, the tag controller may receive a description of the hints used by a network traffic application. In one embodiment, the programmer who develops the network traffic application may publish a description of the various hints the application may provide. A network administrator may access the list and upload it to the tag controller. Alternatively, the tag controller may periodically access, e.g., a central data store to retrieve descriptions of hints user applications may provide. These descriptions may be used to decode a hint transmitted by the network traffic controller to the tag controller. More specifically, the network administrator or tag controller may use the hint descriptions to generate the rules for the hint database. For example, the network traffic application may use a predefined bit value as a hint to indicate that the network flow is expected to be less than a gigabyte (e.g., “0”), while the bit value “1” indicates that the data flow is expected to be greater than a gigabyte. The tag controller may use the description to decode and interpret the hint received from the application to generate one or more rules for assigning a tag based on this hint. In this manner, a programmer may use any code when transmitting a hint and then provide the description of the code to the tag controller using a different communication method—e.g., publishing the description of the hint on a data repository that is accessible to the tag controller or the network administrator. Doing so may reduce the size of the data hint—e.g., the hint may range from one bit to twenty bytes. Once the hint descriptions are generated into rules and placed in the hint database, the tag controller may transmit the hint database to one of the layers in the stack.
In one embodiment, the tag controller may receive the description of the hint before receiving the hint from the network traffic application. For example, the tag controller may periodically download the description of the hints from a central repository or the network administrator may selectively load descriptions of hints into the tag controller based on the type of user applications the network administrator knows will use the SDN enabled network. In one embodiment, the tag controller of network administrator may retrieve the description of the hints after receiving the hint from the network traffic application. The tag controller may receive a coded hint, and if the controller cannot match the hint to a rule in the hint database, the tag controller may attempt to download the description from, for example, the central repository and transmit an updated hint database to one of the layers in the stack which can decode the hint and select the appropriate tag.
In other embodiments, however, the hint may not need a description. That is, the hint provided by the network traffic application may include a description that explains what the hint is. For example, the hint may be the identity of a user that opened a remote connection or the estimated duration of a network flow. In these scenarios, the hint may be larger than the coded hints discussed above but this may enable method 500 to skip block 505. In other words, the hint may be designed such that the computing device can use the hint to select a tag using, for example, a generic version of the hint database without receiving any supplemental description of the hint.
At block 510, the network traffic application may issue a hint associated with one or more network flows generated by the application. As shown in FIG. 4, the network traffic application may issue the hint along a similar data path (e.g., stack 405) as the packets associated with the network flow. In one embodiment, the network traffic application may determine the hint to issue based on an event occurring at the network traffic application. That is, the network traffic application may issue a plurality of different hints that each correspond to a different event. Non-limiting examples of these events include the application first being executed, opening a remote connection, estimating a duration of a network flow or the amount of data a network flow will carry, receiving a query or request for data, and the like. In response to the event, the network traffic application may select a particular hint (or hints). For example, if network traffic application receives a request to transmit a particular table in a database to a user, the application may issue one hint that identifies the user making the request and a second hint providing an estimated duration of the network flow in order to satisfy the query. The network traffic application may issue these hints simultaneously or sequentially.
At block 515, the hint issued by the network traffic application passes through at least one layer in the stack 405 shown in FIG. 4. In one embodiment, the hint or hints may pass through the stack sequentially—e.g., through the network library (e.g., a socket library), operating system, and virtual environment. Alternatively, the hint may pass through only a subset of these layers or may skip layers as the hint traverses the stack. Further still, the hint may pass through the stack only until the hint reaches the layer that is communicatively linked to the tag controller and contains the hint database. If, for example, the hint is embedded in a different data communication, the layer that selects the tag may remove the hint before passing the data communication to a lower level in the stack. In one embodiment, even if a layer of the stack is not tasked with transmitting the hint to the tag controller, the layer may change or amend the hint before passing the hint to a lower level.
In one embodiment, one of the layers in the stack (e.g., a virtual switch or the edge device) may have a flow table (e.g., a superset of the OpenFlow flow table) which may include mask-and-match rules for the SDN enabled network. Specifically, the flow tables may identify a tag or marker that indicates to a SDN enabled network device to take a corresponding action. Actions may include forwarding packets with the tag or marker out a certain port, adding or removing an encapsulation, forwarding through a tunnel to another part of the network, and the like. The SDN controller may publish these rules on the various network devices in the SDN enabled network or even on a virtual switch located in computing device 110 shown in FIG. 1.
At block 520, the layer of the stack with the hint database selects the appropriate tag for the network flow. For example, the operating system on the computing device may identify the hint and select the tag. As mentioned previously, the hint may define the duration of the network flow, the number of bytes likely to be transferred by the network flow, a description of the end points of the flow, an identity of the network traffic application, contractual obligations associated with the flow, and the like. In one embodiment, the network traffic application transmits the hint before generating any network traffic. Alternatively, the network traffic application may provide the hint after starting to transmit a network flow on the SDN enabled network.
In one embodiment, the layer with the hint database may transmit the hint to the tag controller. This may occur, for example, if the hint database does not have a rule matching the hint. Alternatively, instead of storing a local copy of the hint database in the layers of the computing device, the layer may transmit each hint to the tag controller which selects the tag using the database. The tag controller may then transmit the tag back to the layer which can insert the tag into the network flow.
In one embodiment, the network traffic application may generate a plurality of different network flows. Each of these network flows may be associated with a different hint and/or tag. Or the network traffic application may generate a plurality of hints for a single network flow. At block 520, the computing device may evaluate each of the hints independently and select a tag for each of the flows. These tags may be the same or different. In another embodiment, the network traffic application may provide only one hint even if the application generates a plurality of different flows. Nonetheless, the computing device may use the single hint to select multiple tags or select multiple tags for a network flow. Furthermore, if the network traffic application issues multiples hints for a single network flow, the computing device may select a tag for each of the hints.
At block 525, the layer that selects the tag may insert the tag into the network flow. For example, the layer may selectively insert the tag (or tags) into a subset of the packets in the network flow or insert the tag into all the packets in the associated network flow. As mentioned previously, the tag may be any value that, when inserted into a packet, is easily identifiable by a network device—i.e., a value that network device can identify without performing a deep packet inspection.
At block 530, the network administrator may configure the SDN enabled network to perform an action based on identifying the tag in a packet received at a network device. Stated differently, the tag may cause a network device to perform a certain action. This action may include routing the packet to a particular network device, processing the packet using an application executing on the network device, manipulating the packet, discarding the packet, and the like. In one embodiment, the network device may include a table that matches the tag to the corresponding action the network device should perform. In other embodiments, the network device may remove the tag from the packet before forwarding the packet to a different network device.
In one embodiment, the network administrator may configure the network in response to the tag assigned to the network flow using, for example, the SDN controller whose function was discussed previously. Specifically, the network administrator may change or update the routing rules (or control plane) of the edge device such that packets which include the tag are routed to a network device hosting the firewall. As the network traffic application begins to generate packets, the tags are inserted into the packets and the edge device detects the tags and routes the packets accordingly. Thus, in this example, the network administrator may configure the SDN enabled network after receiving the hint from the user application—e.g., the network traffic application.
In another embodiment, the tag controller or the network administrator may base the tag selection on the current configuration of the SDN enabled network. That is, the network administrator may not reconfigure the SDN enabled network based on the received hint, but instead uses the current configuration of the network to select and appropriate tag and action for the network flow.
Regardless of whether the network administrator changes the network configuration after the hint is received or not, the configuration of the network may nonetheless be used to suit the needs of the particular user application without the application's developer having any knowledge of the configuration of network. Accordingly, the network traffic application does not need to be customized for a particular network configuration. Instead, by transmitting the hint, any SDN enabled network may provide a customized tag that causes the underlying network devices to perform an action corresponding to the particular configuration of the network.
Although method 500 discusses selecting a tag based on a hint for a particular network flow (e.g., a plurality of related data packets), the present disclosure is not limited to such. For example, in other embodiments, the computing device may select a tag on a per-packet basis. That is, the network traffic application may transmit a hint which the computing device uses to identify a tag for each packet individually.
FIGS. 6A-6C illustrate initiating a stack for selecting a tag based on received hints, according to embodiments described herein. That is, FIGS. 6A-6C may occur before a hint is issued by a user application. Specifically, FIG. 6A illustrates a system before a virtual machine is initialized in the computing device 110. The computing device 110 includes a hypervisor 605 which may be a portion of software or firmware that creates and manages virtual machines. Here, hypervisor 605 includes a virtual switch 610, but in other embodiments, the virtual switch 610 may not used. The hypervisor 605 may establish communication links 615 and 620 with tag controller 105 and SDN controller 125, respectively. As will be discussed below, communication link 615 may enable the hypervisor 605 to establish a communication link between the tag control 105 and other elements in the computing device 110.
The SDN controller 125 may also establish a communication link 625 to edge device 130 as well as the communication link 620 to the virtual switch 610. Through these links, the SDN controller may establish SDN rules for interpreting tags inserted in received packets. Although two links are shown, in one embodiment, the SDN controller 125 may be communicatively coupled to only one of the links.
In FIG. 6B, hypervisor 605 loads virtual machine 305 into the memory of computing device 110 and begins to execute the operating system 310. Using communication link 615, hypervisor 605 may inform tag controller 105 about virtual machine 305 (or vice versa). Accordingly, tag controller 105 or virtual machine 305 may establish communication link 630 which enables tag controller 105 to pass data (e.g., a hint database) to the virtual machine 305 and/or the operating system 310.
In one embodiment, tag controller 105 may use communication link 615 to load a hint database 635A into the hypervisor 605. As discussed previously, the hint database 635A may be located in multiple layers in the stack or at only select layers and may be used by the layer to select a tag to insert into one or more packets of a network flow based on a hint provided by a user application (e.g., the network traffic application).
In addition, the SDN controller 125 may use communication links 620 and 625 to load flow tables into 640A-B. In one embodiment, SDN controller 125 may load the flow table 640 into one of the networking elements instead of both as shown here. The flow tables 640A-B may include mask-and-match rules (e.g., SDN rules) for the SDN enabled network. Specifically, the flow tables may identify a tag or marker that indicates to a SDN enabled network device to take a corresponding action. Thus, if the layers above the virtual switch 610 and edge device 130 insert a tag into a packet, the flow tables 640A-B enable the network elements to identify the tags and determine the corresponding action to perform.
In FIG. 6C, operating system 310 may load the network traffic application 120 into memory. Here, the operating system 310 may provide application information to tag controller 105. In one embodiment, this application information may be the hint discussed previously. To interpret the hint, tag controller 105 may provide the operating system 310 or virtual machine 305 with a hint database 635B. Moreover, in one embodiment, the tag controller 105 may update the hint databases 635A-B if the tag controller 105 learns more about the hints issued by the network traffic application 120.
In one embodiment, network traffic application 120 may continue to transmit hints to the elements in computing device 110. That is, instead of receiving only one hint from the network traffic application 120 once the application is first loaded into memory, application 120 may issue new hints based on other events such as establishing a new network connection, receiving a user request, or estimating a duration or total data transfer amount of the network flow.
Tag controller 105 may also establish a communication link 632 with the network traffic application 120. Although not shown, tag controller 105 may use this link 632 to load a local copy of the hint database into the network library 320 as discussed above. In this manner, any of the elements (or layers) in computing device 110 (e.g., virtual machine 305, operating system 310, network library 320, or hypervisor 605) may be configured to be in communication with tag controller 105. Using these links, the tag controller 105 may provide updates the hint databases 635.
As will be appreciated by one skilled in the art, embodiments may be embodied as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.
Any combination of one or more computer readable medium(s) may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus or device.
The flowchart and block diagrams in the Figures illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In view of the foregoing, the scope of the present disclosure is determined by the claims that follow.


The present invention relates to the field of aircraft propeller blades, such as those present on turboprops.
Propeller blades for turboprops are generally made of metal material. Although propeller blades made of metal material present good strength, they nevertheless present the drawback of being relatively heavy.
In order to obtain lighter blades, it is known to use propeller blades that are made of composite material, i.e. by making structural parts out of fiber reinforcement and a resin matrix.
Documents US 2013/0017093 and WO 2012/001279 describe making a propeller blade from a streamlined fiber structure into which a portion of a spar is inserted for the purpose of shaping the airfoil portion of the blade so as to form a propeller preform that is subsequently densified with a matrix. The fiber structure, which is made as a single piece by three-dimensional weaving, includes a non-interlinked zone serving to form a housing inside the fiber structure into which a shaping portion of the spar is inserted.
The propeller blade as obtained in that way presents both lower overall weight and considerable mechanical strength as a result of having a skin made of a composite material structure (i.e. fiber reinforcement densified by a matrix).
In order to impart good strength to the most exposed portion of the blade, i.e. its leading edge, the fiber structure does not include any opening or non-interlinked zone in those portions of the fiber structure that are to form the leading edge of the blade. The non-interlinked zone provided inside the fiber structure opens out both into the bottom edge and into the rear edge of the structure so as to form an opening that enables the shaping portion of the spar to be inserted into the inside of the fiber structure.
Nevertheless, in certain circumstances, such as for example when the blade is subjected to high levels of mechanical loading, to impacts, or to shocks, keeping the shaping portion in its reference position inside the densified fiber structure can be difficult, in particular at the rear edge of the fiber structure which is of reduced strength because of the presence of non-interlinking at this location in the fiber structure.


The present invention relates to high temperature superconductors and methods of making same.
Recently, there has been much work done on the utilization of ternary oxides containing rare earth elements. barium, and copper for superconductivity above the temperature of liquid nitrogen. To date, these systems typically require four elements: a rare earth; an alkaline earth; copper; and oxygen. Superconductor systems based on rare earth elements have not been entirely satisfactory. The use of rare earth elements in the production of superconductors increases the cost of the resultant superconductors because these rare earth elements are in relatively short supply and are expensive. Furthermore, these systems typically exhibit limited transition temperatures at or below 93 K. Partial substitutions of elements for the member(s) in these systems have not produced significantly higher temperature superconductors.
Typical high temperature superconductive systems based on rare earth elements also suffer the disadvantage of not being producible in an expedient manner. Therefore, typical methods for producing these high temperature superconductive systems do not provide low cost processing and manufacturability.
Accordingly, there is a need for a new superconductive system and process for making same.


The efficiency with which a computing device can perform a task used to be, in large part, determined by the frequency with which its Central Processing Unit (CPU) could execute computer-readable instructions. CPUs that executed instructions at a higher frequency could perform a greater amount of work within a given time. As the frequency with which CPUs executed instructions began to reach practical limits, computing devices began to include multiple CPUs that could perform multiple tasks in parallel. For such computing devices, if a task was designed, and programmed, such that segments of computer-executable instructions could be executed in parallel, then that task could be performed more efficiently by executing, in parallel, those segments on the multiple CPUs of the computing device.
Unfortunately, for many tasks, the input to one set of computer-executable instructions is based on, or affected by, the output of a prior set of computer-executable instructions. Consequently, such tasks can be difficult to execute in parallel and the execution of such tasks may utilize only one of the multiple CPUs that can be available. Nevertheless, a computing device with multiple CPUs may still provide efficiency benefits, even for tasks that are difficult to parallelize, because users often request the execution of multiple such tasks in parallel, thereby parallelizing the achievement of the user's overall goals.
To provide purchasers of computing devices with expandability, add-on hardware that itself contains one or more CPUs can be added to the computing device. Similarly, virtual computing environments can be used and expandability can, thus, be achieved via the addition of further virtual computing environments. In such cases, however, it may not be practical to extend core software, such as the operating system, to the multiple CPUs or other execution hardware. Instead, the each of the execution environments that were subsequently added can execute their own copy of an operating system or other core software. While such an operating system may be identical to the operating system executing on the original “host” CPU or execution environment, communication between the two, or more, copies of the operating system will be limited to, essentially, inter-computing-device communications. Thus, the addition of such additional computing environment, virtual or physical, to a computing device, can expand the ability of the computing device to execute multiple independent tasks in parallel, but may not expand the ability of the computing device to execute a single, parallelizable, task in a more efficient manner.


1. Field of the Invention
The invention relates to depth filter media.
In this specification "depth filter" means a filter with pores capable of removing from a fluid particles that may be smaller than the size of pores in the filter, the particles being trapped by progressive interception during changes of direction of the pores. Such depth filters have a high dirt capacity.
Depth filters are commonly utilized in the form of a thick continuous cylinder of filter medium that surrounds a central core and may be provided with an external cage. Such depth filters have, because of their low external area and great depth (typically about 15 mm) a relatively high pressure drop when a fluid is passed through the filter. On the other hand, as mentioned above, such filters have relatively high dirt capacity, because of the high internal void space in which contaminant can accumulate.
2. Brief Review of the Prior Art
GB-A-585295 discloses a filter element formed by an elongated web of cellulose filter material folded to extend back and forth between the inner and outer surfaces of the tubular body. The folds extend longitudinally and a tubular binding strip is secured to the inner folds. No drainage layer is provided. GB-A-1389199 discloses a filter formed by corrugating a flat sheet felt medium backed by woven wire. The ends of the sheet are sealed after pleating. The woven wire supports the felt and no drainage layer is provided.
GB-A-1460925 discloses a filter element formed from a corrugated sheet of depth filter medium in which the edges of the sheet are connected together after corrugation. Separate upstream and downstream protective layers are provided. U.S. Pat. No. 4,233,042 discloses a pleated filter medium formed from sheets of glass fibre. EP-A-0083789 discloses a pleated sheet of filter material such as a fibrous filter material. The edges cf the sheet are side-sealed after corrugation.
Although pleating increases the surface area per unit volume of filter material, and thus increases the dirt capacity, the presence of side seals formed after pleating can be disadvantageous. First, the presence of the seal forms an obstruction to uniform flow through the filter element. Secondly, the formation of the side seal requires additional manufacturing steps after pleating (see GB-A-1460925). Thirdly, the presence of a side seal forms a potential leakage path because complete sealing is difficult.
In order to achieve optimum performance of a pleated filter, it is necessary to provide a relatively coarse upstream drainage layer to allow drainage of fluid down between the pleats and to give a void space for the accumulation of dirt. They also support the filter medium. It is also necessary to provide a relatively coarse downstream drainage layer to allow filtrate to drain between the pleats from an inner filtration layer and also to support the filter medium against applied pressure.
The drainage layers are conventionally formed separately from the filter medium by layers of non-woven fabrics or nets located on either side of the filter medium (see GB-A-1460925). The provision of such separate layers and their attachment to the filter medium complicates the manufacture of the filter and increases its cost.


As the size of transistors is reduced to nanometer scale dimensions, for example in the form of ultra-thin body (UTB) silicon-on-insulator (SOI) field effect transistors (FETs), FinFETs and nanowire FETs, the unwanted resistance associated with transistor sources and drains becomes an ever increasing burden on the performance of these devices and of the integrated circuit products manufactured using such transistors. Furthermore, a reduction of dopant activation is predicted theoretically and demonstrated experimentally when the transistor source and drain regions are reduced in size below approximately 10 nm. By dopant activation, we mean desired free carrier (electron or hole) contributions from deliberately introduced impurity species in a semiconductor host. This decrease in nanoscale dopant activation further contributes to undesirably high resistance of doped source/drain (S/D) regions both at the nanoscale metal contacts and within the bulk portion of the nanoscale doped regions. The resistance of metal contacts to a semiconductor increases if effective doping in the semiconductor decreases, the increase being primarily due to the presence of a Schottky barrier at metal-semiconductor contacts.
It is known that a high concentration of doping in a shallow region of semiconductor proximate to a metal-semiconductor interface can reduce the resistance of the metal-semiconductor contact by decreasing the width of the Schottky barrier. Although it is the barrier width that is reduced, from an electrical response point of view (for example current—voltage measurement), it appears that the Schottky barrier height is reduced. An early article that describes this “effective barrier height” reduction by surface doping is by J. M. Shannon, “Control of Schottky barrier height using highly doped surface layers” in Solid-State Electronics, Vol. 19, pp. 537-543 (1976). It is also known that a high concentration of dopant atoms can be introduced into a shallow region of a semiconductor proximate to a metal contact by so-called dopant segregation out of a metal silicide. A. Kikuchi and S. Sugaki reported in J. Appl. Phys., Vol. 53, No. 5, (May 1982) that implanted phosphorus atoms piled up near a PtSi—Si interface during PtSi formation and reduced the measured height of the Schottky barrier to n-type silicon. The reduction of the measured (effective) barrier height of the Schottky diode was attributed to piled up phosphorus atoms in the silicon causing the barrier to be more abrupt. That is, the result was attributed to the effect described by Shannon in 1976.
For the past several decades the silicon microelectronics industry has relied on high doping concentrations in the silicon proximate metal-silicon contacts as a means of obtaining acceptably low contact resistances to transistor sources and drains. The contact metal has for the most part been a metal silicide, most recently nickel silicide or nickel platinum silicide. This approach to minimizing contact resistance is expected to be insufficient in the future as the transistor dimensions continue to shrink and the contact resistance becomes a larger portion of the total resistance between the source and drain (hence becoming a serious performance-limiting factor). The most recent International Technology Roadmap for Semiconductors (ITRS), published in 2011, reports that there is no known solution to the contact resistance problem in bulk MOS transistors when the transistor gate length scales to 18 nm, as expected in year 2014, and a specific contact resistance of no more than 1.0×10−8 Ohm·cm2 is specified. It is becoming increasingly apparent that the Schottky barrier at metal-semiconductor contacts must be reduced in order to reduce the contact resistance to acceptable levels, i.e. well below 1.0×10−8 Ohm·cm2 in the case of MOS transistor doped source/drain contacts. A technology that is capable of reducing the Schottky barrier and hence reducing the resistance of contacts to doped semiconductor regions may also be applied to so-called “metal source/drain transistors” which do not have doped source and drain but rather utilize a direct contact between the metal and the transistor channel (the region of free carriers that are modulated by the electrical potential on a gate and that transport current between the source and the drain).
A body of work published in 1991-1992 reported experimental verification of theoretical predictions by Baroni, Resta, Baldereschi and others that a double intralayer formed by two different elements would create an interface dipole, capable not only of modifying heterojunction band discontinuities, but also of generating band discontinuities in homojunctions. McKinley et al. first reported obtaining 035-0.45 eV band offsets at {111}-oriented Ge homojunctions using Ga—As dipole intralayers in a 1991 article “Control of Ge homojunction band offsets via ultrathin Ga—As dipole layers”, J. Vac. Sci. Technol. A 9 (3), May/June 1991 and in a similar article in 1992 “Control of Ge homojunction band offsets via ultrathin Ga—As dipole layers”, Applied Surface Science Vol. 56-58, pp. 762-765 (1992).
Arsenic, gallium, and germanium depositions were done at room temperature on p-type Ge(111) substrates. Valence band offsets were measured by in situ core level x-ray photoluminescence. The deposited Ge region (overlayer) had a valence band offset to the Ge substrate as manifested by a splitting of the Ge 3d core level into two components; one due to the Ge substrate and the other to the Ge overlayer. Both positive and negative valence band offsets were obtained in Ge homojunctions by introducing Ga—As dipole intralayers with either “Ga-first” or “As-first” growth sequences. The band offset was found to be 0.35-0.45 eV with the Ge valence band edge on the As side of the junction at a lower energy (i.e., more bound). Dipole intralayers were explained on the basis of the Harrison “theoretical alchemy” model described by W. A. Harrison et al. in “Polar Heterojunction Interfaces”, Phys. Rev. B 18, 4402 (1978). Intralayer control of band discontinuities was thus applied to homojunctions, expanding the potential domain of band offset engineering beyond semiconductor heterojunctions.
In 1992, Marsi et al. followed up on the reports by McKinley et al. with the articles “Microscopic manipulation of homojunction band lineups”, J. Appl. Phys., Vol. 71, No. 4, 15 Feb. 1992, “Homojunction band discontinuities induced by dipolar intralayers: Al—As in Ge”, J. Vac. Sci. Technol. A 10(4), July/August 1992 and “Local nature of artificial homojunction band discontinuities”, J. Appl. Phys. 72 (4), 15 Aug. 1992. In the first article, Marsi et al. reported valence-band discontinuities at Si—Si and Ge—Ge homojunctions when III-V double intralayers of atomic thickness were inserted at the interfaces. Valence band discontinuities were again measured by in situ core level x-ray photoluminescence. In Ge samples, a deposited Ge region (overlayer) had a valence band offset to a Ge substrate as evidenced by a splitting of the Ge 3d core level into two components and a deposited Si region had a valence band offset to a Si substrate as evidenced by a splitting of the Si 2p core level. The observed discontinuities with magnitudes in the range 0.4 to 0.5 eV (for example 0.5 eV for Si—P—Ga—Si and 0.4 eV for Si—P—Al—Si) were in qualitative agreement with theoretical predictions although most theories estimate larger valence band discontinuities due to the dipole effect. A III-V intralayer at a group-IV homojunction systematically induced an artificial valence-band discontinuity when the anion was deposited first. It was also reported that in the case of Si—Si homojunctions with Al—P or Ga—P intralayers, a reversal of the interface deposition sequence led to a reversal of the valence-band discontinuity, as expected.
In the second article it was shown, again using x-ray photoemission, that a similar band offset effect can be induced using Al—As as a “dipolar intralayer” between two regions of {111}-oriented germanium. Specifically, an offset of 0.4 eV was obtained for the “anion-first” Ge(substrate)-As—Al—Ge(overlayer) sequence, consistent with the “anion-first” As—Ga sequence reported by McKinley, the overlayer component exhibiting a lower binding energy with respect to the substrate component. In the third article, multiple III-V bilayer (intralayer) stacks were investigated. The measured value of valence band offset remained the same, 0.5 eV, for an individual double layer, for double-stacked bilayers and for triple-stacked bilayers. Experiments performed on 2(Ga—P) and 2(P—Ga) were fully consistent with those on 2(Al—P) and 2(P—Al); no substantial increase was observed on going from the individual bilayers to two bilayers or even to three bilayers. It was therefore concluded that stacked interfacial III-V bilayers do not increase the effect of an individual bilayer, contrary to elementary predictions based on sequential dipoles.
In U.S. Pat. Nos. 7,084,423, 7,176,483, 7,462,860, and 7,884,003 and in pending U.S. patent application 2011/0169124, Grupp and Connelly described metal-semiconductor contacts having an interfacial layer at the interface between a metal and a group IV semiconductor for the purpose of reducing the Schottky barrier at the contact and, hence, reducing the specific resistivity of the contact. A monolayer of arsenic (or nitrogen) was included amongst the possible embodiments/specifications of the interfacial layer.


Boron neutron capture therapy (BNCT) is a unique tumor cell targeting therapy (Soloway et al, Chem. Rev. 98:1515-1562, 1998; Barth et al., Clinical Res. 11:3987-4002, 2005). It is one of the binary cancer treatment systems that are based on the selective accumulation of boron-10 (10B) in tumors followed by irradiation with a neutron source. The selective accumulation of 10B in tumors and the subsequent capture of an epithermal neutron by a 10B atom, which produces an α-particle (He2+) and a lithium nucleus (7Li+) ejected in opposite directions within the tumor mass, make BNCT an attractive therapy for targeting tumors. The average track of these densely ionizing particles is approximately 14 μm, about the diameter of one cell, so that the killing of tumor cells is highly efficient (see Barth et al., Cancer 70:2995 3007, 1992; Barth et al., Neurosurg. 44:433 451, 1999; Soloway et al., J. Neurooncol. 33:9-18, 1997; and Soloway et al., 1998, supra). This promising radiation therapy requires the administration of tumor-seeking compounds containing 10B atoms that concentrate preferentially in tumor cells prior to irradiation with suitable low energy neutron beams. This binary modality is a highly attractive cancer therapy in that neither the thermal neutrons nor the boron carrier molecule has significant cytotoxic effect alone, but in combination they produce highly radiobiologically effective particles. The alpha particle and Li ion that are released as fission products when a thermal neutron is absorbed by a 10B atom have high linear energy transfer (LET) and a range similar to the dimensions of a mammalian cell. Thus, the absorbed dose, which is potent, is confined to cells adjacent to the boron atoms. The potential exists, therefore, to destroy tumor cells by radiosurgery at the microscopic level while sparing normal tissue in the vicinity of the tumor. BNCT is especially attractive for malignant brain tumors because it targets and destroys malignant cells but spares normal cells, thus preventing undesirable side effects common in standard chemo- or radiotherapy.
In recent years, several research groups have developed a variety of 10B carriers, including porphyrin derivatives with improved tumor selectivity over prior boron neutron capture agents, such as disodium mercapto-closo-dodecaborate (BSH) and L-4-dihydroxy-borylphenylalanine (BPA). Porphyrin derivatives are currently being tested in clinical trials in the U.S., Europe, and Japan for the treatment of patients with glioblastomas and melanomas (see, e.g., Bonnett et al., Chem. Soc. Rev. 24:19-33, 1995; Kageji et al., J. Neurooncol. 33:117-130, 1997; Pignol et al., Br. J. Radiol. 71:320-323, 1998; Elowitz et al., Neurosurgery 42:463-469, 1998). Although BSH and BPA have been shown to be safe and efficacious in animal models, several problems remain. For instance, BSH is sensitive to air-oxidation (Tolpin et al., Inorg. Chem. 17:2867-2873, 1978) and both BSH and BPA have low retention times in tissues and only moderate selectivity for tumor cells (Capala et al., Radiation Res. 146:554-560, 1996). At present, clinical progress is stalled due to the absence of effective boron delivery agents that target tumor cells with high selectivity. Obviously, the ultimate success of BNCT will be dependent upon whether adequate concentrations of boron neutron capture agents and low-energy neutrons can be selectively and effectively delivered to tumor cells.
Hypoxic tumor cells that comprise up to 50% of the mass of viable cells in human tumors pose a special impediment to effective radio- and chemotherapy. In particular, hypoxic cells are highly radio-resistant and capable of proliferation following radiation treatment. If boron containing therapeutics that interact with epithermal neutrons are not delivered to hypoxic sites in tumors it can be anticipated that the effectiveness of BCNT will be significantly compromised. In principal, BNCT is well suited to treating poorly oxygenated tumors since reduced radio-sensitivity in the absence of oxygen is less pronounced for high LET radiations, yet the effectiveness of BNCT therapy is dependent on delivery of the agent carrying the 10B atom to the tumor site.
2-nitroimidazoles readily penetrate tumors and can reach intratumor concentrations approaching 1 mM. As Varghese et al. showed in 1976 (Scobie et al., 1994), 2-nitroimidazoles also undergo nitroreductive activation under hypoxic conditions to yield electrophilic species that form adducts with cellular macromolecules, such as DNA and proteins. These adducts are retained in hypoxic cells and represent a useful targeting mechanism. In fact, carboranes have been linked to nitroimidazoles (Wood et al., 1996; Swenson et al., 1996) in attempts to target boron selectively to the hypoxic regions of tumors, but these boron delivery agents suffered greatly from poor water solubility. Thus, there remains a need for highly effective reagents for use in treating tumor tissue.


1. Field of the Invention
This invention relates to a simplified, potential low cost system for drywall tape installation.
Since the tape is fully imbedded after only one operation, there is a reduction in labor to complete the drywall taping procedure.
2. Background Art
The repetitive and laborious process of taping drywall has lead to several systems of taping, each of which have serous undersirable limitations.
Since the advent of drywall technology, the taping of the seams created when sheets of drywall are nailed in place has been a pedestrian exercise in handling the paper tape and adhesive wet mud. The components are currently sold separately and are combined only upon actual application with all prior art.
In the time consuming manual application of the taping materials, the adhesive mud is manually scooped out of a container and applied with a smearing action to drywall seams with a drywall knife. Then dry paper tape is un-rolled and laid upon the adhesive surface and wiped down onto the wet mud. The tape is later top coated with more mud and wiped smooth after each coat to flatten the surface. The materials are allowed to dry between coats.
One layer of mud goes under the tape to achieve adhesion and at least two layers of mud are commonly applied over the tape to "embed" the tape within the mud. The mud is allowed to dry between coats. Mud is applied to the drywall seams and wiped down until the mud appears smooth and the gap between the drywall panels are made flat.
The predominate commercial taping system in use, is the Ames system. The Ames system consist of a series of tools designed to handle both dry, non-adhesive paper tape and wet adhesive mud to make the application procedure faster than manual installation.
The Ames system tape tools consist of; a manual mud pump, a taper tool, roller, finishers and a standard drywall knife. Many of the Ames tools are complex, rather expensive and require extensive training, adjustment and manual dexterity to operate.
In the Ames system the drywall mud is pumped out of a bucket into a cylinder within the Ames taper. The Ames taper tool holds a roll of dry paper tape. When the cylinder is full of mud the taper is held against the seam and the taper head is rolled along the seam. The cylinder is emptied of the mud it holds, as a wheel on the head which contains a pulley, reels up a steel cable attached to a piston within the cylinder. The mud then exits the tool out a hole at the head as dry paper tape is rolled onto the mud as it is ejected upon the wall.
The seam must be "wiped down with a drywall knife to complete the taping operation with the Ames system. The seam then requires a top coat of mud to fully imbed the tape.
With the Ames system full embedding occurs only after three operations; Tape and mud application to the drywall, wiping the tape down and then top coating the seam.
The previously mentioned tools have various limitations and short comings. The Ames system is very expensive as it requires many unique part be machined and the tools maintained in proper adjustment. The taper tool is heavy and hard to use. The Ames taper requires that many precision parts operate in the hostile environment of gritty, adhesive viscous drywall mud. The tool must be cleaned, oiled and adjusted often to not breakdown or become jammed and stop working. Parts wear out and break requiring substantial maintenance and expense. The Ames taper does not apply mud to the top side of the drywall tape.
A more primitive taping tool called the "banjo" utilizes the concept of a reel of dry tape that is threaded though a chamber of wet mud as it exits the tool and the muddy tape is then directly applied to the drywall for manual wipe down. As the banjo concentrates all the mud under the tape, very little mud ends up on the back side of the tape. With a banjo taper another coat of mud must be applied to fully embed the tape.
The banjo is slow and inefficient as the mud may not properly and fully coat the underside of the tape, leaving a dry blister under the tape. The banjo is heavy and awkward to use and requires that the muddy tape be wiped down after it is unrolled upon the drywall seam. The banjo will not readily do inside corners and does not apply mud to both sides of the drywall tape.
It would be desirable to have an effective labor saving system that is inexpensive to manufacture, easy to use and light weight. The system should be able to operate in the hostile environment of the materials and not be adversely affected by the mud drying and or a failure to thoroughly clean the tools after each use.
The system should utilize current materials and procedures common to the drywall taping industry. Use of the tools should be natural and easy to learn. It would be desirable to reduce the occurrence of blisters of air which occasionally occur under the tape. The system should fully embed the drywall tape in the initial application; thus reducing the number of required steps and eliminating some labor.


The invention relates to a method for producing a semiconductor structure having a plurality of vertical and at least one lateral semiconductor component integrated in a disk-shaped semiconductor body having a first surface and a second surface opposite the first surface, with the lateral semiconductor components being disposed beneath the first surface, and the plurality vertical semiconductor components extending between the first and the second surfaces. The at least one lateral semiconductor component being disposed inside a partial structure which is insulated from adjacent regions. The thickness of the semiconductor body is reduced in the region of the partial structure. As used herein, the term semiconductor component is intended to mean semiconductor device or devices integrated into a semiconductor body.
A method of producing, such a semiconductor structure is disclosed in EP-A-0,193,172. In this instance, a vertical MOS transistor is described which is disposed in a semiconductor body along with a lateral switching circuit. The MOS transistor and the lateral switching circuit are isolated from one another by a p-n junction. It does not follow from EP-A-0,193,172 to integrate a plurality of vertical components in the semiconductor body. A disadvantage in the disclosed type of insulation EP-A-0,193,172 is that the space-charge region present at the p-n junction requires a great deal of space that cannot be used for the insertion of components. Moreover, the doping of the regions lying adjacent to the isolation cannot be freely selected; namely--for obtaining a space-charge region--a p-doped and an n-doped zone must always be present alternatingly so that a p-n junction results. Furthermore, it is disadvantageous that, at a p-n junction, the correct polarity (in the blocking direction) must be heeded, because otherwise the isolating effect of the junction is lost. The permitted potential in the one region is therefore a function of that in the other region--located behind the p-n junction.


The invention relates to a method for the manufacture of a wire electrode for the spark-erosion process and a wire electrode for this method, which consists of a core of steel, an intermediate layer of copper or a high copper-containing alloy, and an outer layer with at least 40% zinc or a core of steel and a zinc alloy outer layer having a zinc content of from 40-60%.
Wire electrodes, which are designed with multiple layers, which have a core of steel, an intermediate layer of copper arranged around the core, and an outer zinc-containing layer, are known, for example, from the DE-PS 29 06 245. All known wire electrodes, which are constructed with a steel core, do indeed have an increased strength compared with copper or brass electrodes, however, all of these erosion electrodes have the disadvantage that if they have comparatively high strengths, their electrical conductivity is very low and merely reaches 8 Sxc2x7m/mm2. This comparatively high tensile strength is particularly advantageous for the cutting of high or thick workpieces or, however, also for the cutting of very small parts since high wire tensions are here demanded. However, these known wire electrodes have the disadvantage that their erosion performance is relatively low. In particular, in the case of cutting very small parts with erosion-wire diameters of up to 10 xcexcm, high wire strengths are demanded in order to reduce deflection and vibration of the wire to a minimum. Tungsten or molybdenum wires have been used up to now for the cutting of very small parts with wire thicknesses of 100 xcexcm and less, however, tungsten or molybdenum wires are extremely expensive to manufacture. Erosion wires with a steel core and a brass outer layer have been unable to be successful up to now for this purpose since they always, in comparison to tungsten wires, showed a lesser strength and a poorer erosion behavior.
The basic purpose of the invention is to provide high-strength erosion electrodes with a core of steel of the abovementioned type and a method for their manufacture, which electrodes have strengths which are 1800 N/mm2 and higher and, in addition, have a comparatively high conductivity of 10 Sxc2x7m/mm2 and more.


For example, an Li ion battery is known as a high-voltage and high-energy density battery. The Li ion battery is a cation-based battery utilizing a reaction between an Li ion and a cathode active material and a reaction between an Li ion and an anode active material. Meanwhile, as an anion-based battery, a fluoride ion battery utilizing a reaction of a fluoride ion is known.
Also, it is known that an ionic liquid is used for a liquid electrolyte. For example, in Patent Literature 1, a nonaqueous electrolyte secondary battery provided with an electrolyte having an ionic liquid and a lithium salt is disclosed. In addition, as the ionic liquid, an ionic liquid containing fluoride complex anions such as 1-butylpyridinium tetrafluoroborate is disclosed.
Also, in Patent Literature 2, a fluoride ion battery provided with an electrolyte dissolving a fluoride salt in a solvent and an addition agent including a fluoride composite producing species is disclosed. In addition, examples of the solvent include an ionic liquid (claim 14). Also, examples of the fluoride composite producing species include tris(pentafluorophenyl)borane (claim 3).


1. Field of the Invention
The present invention relates to a lamp and, more particularly, to a lamp such as a wall lamp, night lamp and the like.
2. Description of the Related Art
A conventional lamp comprises a base, a lamp socket mounted on the base, a light emitting member mounted on the lamp socket, and an outer shade mounted on the base to surround the light emitting member. Thus, the base is mounted on a wall (or ceiling) to attach the lamp onto the wall to provide a lighting effect. The outer shade of the lamp is provided with patterns to enhance the outer appearance of the lamp. However, the outer shade of the lamp has a fixed structure so that the patterns of the outer shade lack variation, thereby limiting the versatility of the lamp.


Traditional methods for detecting biological compounds in vivo and in vitro rely on the use of radioactive markers. For example, these methods commonly use radiolabeled probes such as nucleic acids labeled with 32P or 35S and proteins labeled with 35S or 125I to detect biological molecules. These labels are effective because of the high degree of sensitivity for the detection of radioactivity. However, many basic difficulties exist with the use of radioisotopes. Such problems include the need for specially trained personnel, general safety issues when working with radioactivity, inherently short half-lives with many commonly used isotopes, and disposal problems due to full landfills and governmental regulations. As a result, current efforts have shifted to utilizing non-radioactive methods of detecting biological compounds. These methods often consist of the use of fluorescent molecules as tags (e.g. fluorescein, ethidium, methyl coumarin, rhodamine, and Texas red), or the use of chemiluminescence as a method of detection. Presently however, problems still exist when using these fluorescent and chemiluminescent markers. These problems include photobleaching, spectral separation, low fluorescence intensity, short half-lives, broad spectral linewidths, and non-gaussian asymmetric emission spectra having long tails.
Fluorescence is the emission of light resulting from the absorption of radiation at one wavelength (excitation) followed by nearly immediate reradiation usually at a different wavelength (emission). Fluorescent dyes are frequently used as tags in biological systems. For example, compounds such as ethidium bromide, propidium iodide, Hoechst dyes, and DAPI (4′,6-diamindino-2-phenylindole) interact with DNA and fluoresce to visualize DNA. Other biological components can be visualized by fluorescence using techniques such as immunofluorescence which utilizes antibodies labeled with a fluorescent tag and directed at a particular cellular target. For example, monoclonal or polyclonal antibodies tagged with fluorescein or rhodamine can be directed to a desired cellular target and observed by fluorescence microscopy. An alternate method uses secondary antibodies that are tagged with a fluorescent marker and directed to the primary antibodies to visualize the target.
Another application of fluorescent markers to detect biological compounds is fluorescence in situ hybridization (FISH). This method involves the fluorescent tagging of an oligonucleotide probe to detect a specific complementary DNA or RNA sequence. An alternative approach is to use an oligonucleotide probe conjugated with an antigen such as biotin or digoxygenin and a fluorescently tagged antibody directed toward that antigen to visualize the hybridization of the probe to its DNA target. FISH is a powerful tool for the chromosomal localization of genes whose sequences are partially or fully known. Other applications of FISH include in situ localization of mRNA in tissues samples and localization of non-genetic DNA sequences such as telomeres.
Fluorescent dyes also have applications in non-cellular biological systems. For example, the advent of fluorescently-labeled nucleotides has facilitated the development of new methods of high-throughput DNA sequencing and DNA fragment analysis (ABI system; Perkin-Elmer, Norwalk, Conn.). DNA sequencing reactions that once occupied four lanes on DNA sequencing gels can now be analyzed simultaneously in one lane. Briefly, four reactions are performed to determine the positions of the four nucleotide bases in a DNA sequence. The DNA products of the four reactions are resolved by size using polyacrylamide gel electrophoresis. With singly radiolabeled (32P or 35S) DNA, each reaction is loaded into an individual lane. The resolved products result in a pattern of bands that indicate the identity of a base at each nucleotide position. This pattern across four lanes can be read like a simple code corresponding to the nucleotide base sequence of the DNA template. With fluorescent dideoxynucleotides, samples containing all four reactions can be loaded into a single lane. Resolution of the products is possible because each sample is marked with a different colored fluorescent dideoxynucleotide. For example, the adenine sequencing reaction can be marked with a green fluorescent tag and the other three reactions marked with different fluorescent colors. When all four reactions are analyzed in one lane on a DNA sequencing gel, the result is a ladder of bands consisting of four different colors. Each fluorescent color corresponds to the identity of a nucleotide base and can be easily analyzed by automated systems.
There are chemical and physical limitations to the use of organic fluorescent dyes. One of these limitations is the variation of excitation wavelengths of different colored dyes. As a result, simultaneously using two or more fluorescent tags with different excitation wavelengths requires multiple excitation light sources. This requirement thus adds to the cost and complexity of methods utilizing multiple fluorescent dyes.
Another drawback when using organic dyes is the deterioration of fluorescence intensity upon prolonged exposure to excitation light. This fading is called photobleaching and is dependent on the intensity of the excitation light and the duration of the illumination. In addition, conversion of the dye into a nonfluorescent species is irreversible. Furthermore, the degradation products of dyes are organic compounds which may interfere with biological processes being examined.
Another drawback of organic dyes is the spectral overlap that exists from one dye to another. This is due in part to the relatively wide emission spectra of organic dyes and the overlap of the spectra near the tailing region. Few low molecular weight dyes have a combination of a large Stokes shift, which is defined as the separation of the absorption and emission maxima, and high fluorescence output. In addition, low molecular weight dyes may be impractical for some applications because they do not provide a bright enough fluorescent signal. The ideal fluorescent label should fulfill many requirements. Among the desired qualities are the following: (i) high fluorescent intensity (for detection in small quantities), (ii) a separation of at least 50 nm between the absorption and fluorescing frequencies, (iii) solubility in water, (iv) ability to be readily linked to other molecules, (v) stability towards harsh conditions and high temperatures, (vi) a symmetric, nearly gaussian emission lineshape for easy deconvolution of multiple colors, and (vii) compatibility with automated analysis. At present, none of the conventional fluorescent labels satisfies all these requirements. Furthermore, the differences in the chemical properties of standard organic fluorescent dyes make multiple, parallel assays quite impractical since different chemical reactions may be involved for each dye used in the variety of applications of fluorescent labels.


1. Field of the Invention
The present invention relates to a structure of ESD protection circuits on a BEOL layer and a method of fabricating the same.
2. Description of the Prior Art
There are various types of circuits which protect against Electrostatic Discharge (ESD). ESD means a discharge from an electrostatically charged person or machine to a semiconductor device, a discharge from a charged semiconductor device to earth, and the like. When ESD occurs in a semiconductor device, a large amount of electric charge flows from the terminals of the semiconductor device into the semiconductor device, which raises the voltage inside the semiconductor device and may cause a dielectric breakdown of the internal circuits of the semiconductor device.
Conventional ESD protection circuits are disposed at a same level of the internal circuits. These circuits occupy too much space, however, which influences the potential miniaturization of the semiconductor device.


In the field of electronic devices, such as systems on a chip, a phase lock loop is often used to generate a master clock signal. That master clock signal is then divided downward into a variety of different clock signals for use by different components within the system on chip.
This division is performed by coupling multiple divider circuits to the output of the phase locked loop. For example, a divide by 2, a divide by 4, and a divide by 8 divider circuit are each coupled to the phase locked loop. However, this approach has drawbacks. For example, power consumption may be undesirably high.
It is therefore desirable for new divider circuits to be developed.


A great deal of time, money, and effort is spent in the fight against security risks, such as viruses, malware, exploits, intrusions, and other dangers to enterprise computing. A malware infection may require a compromised system to be erased and re-imaged to remove the malware, which can also result in great expenditures of time and money as well as loss of productivity.
While terms such as viruses, malware, and exploits may have specific definitions in the art, as used herein the term “malware” shall refer to any type of computer code and/or other data introduced from outside a computer system or network of computers that may be used to damage or otherwise cause aspects of the computer system or network of computers to malfunction or perform in an unintended manner. Thus, as used herein, the term “malware” encompasses viruses, exploits, worms, and any type of programmatic security risk.
Malware may be introduced into a computer network through a wide variety of avenues, such as email or a malformed JPEG or other code on a web page that is downloaded to a computer via a web browser. Malware generally follows a common lifecycle; namely, the malware will exploit a weakness in the computer system or network, the malware will drop and execute a payload, the malware will attempt to escalate its privileges, the malware will take steps to persist on the system and/or network despite efforts to remove it, and finally the malware will propagate to other computers. If the malware is unable to be detected using current approaches, then countermeasures cannot be enacted and systems may become infected.


1. Field of the Invention
The invention relates to a time switch whereby the on and off states of internal contact points control the operation of an electrical load according to a time schedule.
2. Description of the Background Information
A conventional time switch, such as the type described in Japanese Kokai (laid open) Patent S63-29427, includes a modular structure assembled from a motor that rotates at a uniform speed, a ratchet gear driven by a gearwheel transmission powered by the motor, and a first gear that meshes with the ratchet gear. The time switch also includes a sub-dial that rotates clockwise at a rate of one revolution per hour relative to the rotation of the ratchet gear, a gear that meshes with a second gear attached to the rotating shaft of the sub-dial, a dial that rotates clockwise once during a 24-hour period relative to the rotation of the sub-dial, a scheduling clip with a finger that projects from the circumference of a dial used to set a desired operating time schedule, and an internal contact point activating mechanism that opens and closes the contact points through contact with a contact element that is freely settable to a desired time. In the time switch of Japanese Kokai (laid open) Patent S63-29427, the ratchet gear, which is rotatably driven by motor torque supplied through the gearwheel transmission, rotatably drives the sub-dial through the sub-dial shaft. Although the dial is rotationally driven by meshing with the second gear on the sub-dial shaft, the sub-dial shaft rotates only in one direction due to the ratchet mechanism formed by the first gear and ratchet gear at the rotating sub-dial shaft. As a result, even though the sub-dial can be turned manually to set the time, it can only be turned in one direction, thereby making it time-consuming to set the time. For example, when changing the time schedule due to the enactment of daylight savings time, it would be easy to turn the sub-dial back one hour from a current setting of 7 o'clock to a 6 o'clock setting. Because the sub-dial can only be turned in the clockwise direction, however, it must be advanced 23 hours to effect the desired time change. As a result, changing the time becomes a time-consuming operation.