Patent Grant
11765075
One or more aspects relate, in general, to facilitating processing within a computing environment, and in particular, to facilitating processing relating to traversal of a network of the computing environment.
Some computing environments provide Infrastructure as a Service (IaaS), in which compute, storage and/or networking resources are provided on demand and charged based on utilization. For such environments, charging based on use can be difficult, especially when there are many users using the same resources.
Shortcomings of the prior art are overcome, and additional advantages are provided through the provision of a computer-implemented method of facilitating processing within a computing environment. The computer-implemented method includes obtaining, at one device of a network, a packet of data and determining a path from the one device to a next device of the network. At least one toll value for the path from the one device to the next device is determined and based on the at least one toll value for the path from the one device to the next device, a routing toll is adjusted. The routing toll is stored in a frame used in routing the packet of data in the network.
Computer systems and computer program products relating to one or more aspects are also described and may be claimed herein. Further, services relating to one or more aspects are also described and may be claimed herein.
Additional features and advantages are realized through the techniques described herein. Other embodiments and aspects are described in detail herein and are considered a part of the claimed aspects.
One or more aspects are particularly pointed out and distinctly claimed as examples in the claims at the conclusion of the specification. The foregoing and objects, features, and advantages of one or more aspects are apparent from the following detailed description taken in conjunction with the accompanying drawings in which:
In one or more aspects, processing within a computing environment is facilitated. As an example, processing relating to traversal of a network of the computing environment is facilitated. A capability is provided, in or more aspects, to perform tolling (e.g., automatically) as a packet of data is routed through a network. For instance, an automated tolling mechanism is provided that accounts for use of different parts of the network as a packet traverses through the network. This enables accurate invoicing for the utilization of network resources in the routing of the packet.
In one example, each selected connection of a network (e.g., each or selected inter-switch links (ISL) or other connections) has at least one toll value associated therewith, which is used to determine a toll should that connection be traversed in routing a packet. For instance, a connection between device A of a network and device B of the network is assigned at least one toll value. The toll value assigned to a particular connection is based on, for instance, one or more of: a length of the connection, the speed of the connection, bandwidth (trunk/port channels link count), usage, user input, service provider input, etc. Additional, fewer and/or other factors may be considered when assigning a toll value. Further, a connection may have one toll value for a packet travelling in one direction (e.g., A to B) and another toll value for the opposite direction (e.g., B to A). Moreover, a connection may be assigned a static value that does not change based on changing factors or a dynamic value that does change depending on the factors. As examples, a particular link may have one toll value based on one time of day (e.g., peak hours) and another toll value based on another time of day (e.g., non-peak hours); may have a toll value that changes based on congestion of the connection, etc.; may have one or more toll values associated therewith depending on one or more factors. Many variations are possible.
As examples, the toll value may be a cost for that connection (e.g., a fee or toll for using that connection, e.g., a monetary value) or the toll value may be a weight (e.g., a numerical value), which is used to determine a cost for that connection. For instance, a mathematical equation or formula may be applied to the weight to determine the cost. As an example, the weight may be multiplied by a number to obtain the cost. In one or more examples, the weight may be static, but the determination of the cost based on the weight might be dynamic to adjust for changing factors. In other examples, the weight is dynamic and changes based on one or more factors. Many possibilities exist for determining the cost based on a weight. Further, many possibilities exist as example toll values, each of which may be static or dynamic.
In one or more examples, components, in addition to or in lieu of connections, may have toll values associated therewith. As examples, network appliances that have security and/or analytics, other network appliances, devices, etc. may have a toll value assigned thereto. In such cases, each toll value for each component that is part of the route is used to determine a toll. Many examples are possible.
Further, in one or more aspects, a capability is provided to enable different routing policies to be used, e.g., for different users, to route packets through the network. As examples, one routing policy optimizes latency at a higher cost, while another routing policy optimizes cost (e.g., lower cost) at a possible higher latency. The user is able to set one or more policies that determine or affect cost for traversal of a packet. A policy may be static or dynamic; it may be for a given time of day, given day, type of packet or any other basis in which a policy may be set for a packet. For instance, a policy may be set for high-peak hours in which the fastest route is taken regardless of costs and another policy may be set for low-peak hours in which the least expensive route is to be taken. Many different policies may be supported, and a user may define one or more policies for the traversal of their packets.
One or more aspects of the present invention are incorporated in, performed and/or used by a computing environment. As examples, the computing environment may be of various architectures and of various types, including, but not limited to: personal computing, client-server, distributed, virtual, emulated, partitioned, non-partitioned, cloud-based, quantum, grid, time-sharing, cluster, peer-to-peer, mobile, having one node or multiple nodes, having one processor or multiple processors, and/or any other type of environment and/or configuration, etc. that is capable of executing a process (or multiple processes) that, e.g., performs automatic tolling and/or performs one or more other aspects of the present invention. Aspects of the present invention are not limited to a particular architecture or environment.
Various aspects of the present disclosure are described by narrative text, flowcharts, block diagrams of computer systems and/or block diagrams of the machine logic included in computer program product (CPP) embodiments. With respect to any flowcharts, depending upon the technology involved, the operations can be performed in a different order than what is shown in a given flowchart. For example, again depending upon the technology involved, two operations shown in successive flowchart blocks may be performed in reverse order, as a single integrated step, concurrently, or in a manner at least partially overlapping in time.
A computer program product embodiment (“CPP embodiment” or “CPP”) is a term used in the present disclosure to describe any set of one, or more, storage media (also called “mediums”) collectively included in a set of one, or more, storage devices that collectively include machine readable code corresponding to instructions and/or data for performing computer operations specified in a given CPP claim. A “storage device” is any tangible device that can retain and store instructions for use by a computer processor. Without limitation, the computer readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these mediums include: diskette, hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or Flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device (such as punch cards or pits/lands formed in a major surface of a disc) or any suitable combination of the foregoing. A computer readable storage medium, as that term is used in the present disclosure, is not to be construed as storage in the form of transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, light pulses passing through a fiber optic cable, electrical signals communicated through a wire, and/or other transmission media. As will be understood by those of skill in the art, data is typically moved at some occasional points in time during normal operations of a storage device, such as during access, de-fragmentation or garbage collection, but this does not render the storage device as transitory because the data is not transitory while it is stored.
One example of a computing environment to perform, incorporate and/or use one or more aspects of the present invention is described with reference to
Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer or any other form of computer or mobile device now known or to be developed in the future that is capable of running a program, accessing a network or querying a database, such as remote database 130. As is well understood in the art of computer technology, and depending upon the technology, performance of a computer-implemented method may be distributed among multiple computers and/or between multiple locations. On the other hand, in this presentation of computing environment 100, detailed discussion is focused on a single computer, specifically computer 101, to keep the presentation as simple as possible. Computer 101 may be located in a cloud, even though it is not shown in a cloud in
Processor set 110 includes one, or more, computer processors of any type now known or to be developed in the future. Processing circuitry 120 may be distributed over multiple packages, for example, multiple, coordinated integrated circuit chips. Processing circuitry 120 may implement multiple processor threads and/or multiple processor cores. Cache 121 is memory that is located in the processor chip package(s) and is typically used for data or code that should be available for rapid access by the threads or cores running on processor set 110. Cache memories are typically organized into multiple levels depending upon relative proximity to the processing circuitry. Alternatively, some, or all, of the cache for the processor set may be located “off chip.” In some computing environments, processor set 110 may be designed for working with qubits and performing quantum computing.
Computer readable program instructions are typically loaded onto computer 101 to cause a series of operational steps to be performed by processor set 110 of computer 101 and thereby effect a computer-implemented method, such that the instructions thus executed will instantiate the methods specified in flowcharts and/or narrative descriptions of computer-implemented methods included in this document (collectively referred to as “the inventive methods”). These computer readable program instructions are stored in various types of computer readable storage media, such as cache 121 and the other storage media discussed below. The program instructions, and associated data, are accessed by processor set 110 to control and direct performance of the inventive methods. In computing environment 100, at least some of the instructions for performing the inventive methods may be stored in block 150 in persistent storage 113.
Communication fabric 111 is the signal conduction paths that allow the various components of computer 101 to communicate with each other. Typically, this fabric is made of switches and electrically conductive paths, such as the switches and electrically conductive paths that make up busses, bridges, physical input/output ports and the like. Other types of signal communication paths may be used, such as fiber optic communication paths and/or wireless communication paths.
Volatile memory 112 is any type of volatile memory now known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, the volatile memory is characterized by random access, but this is not required unless affirmatively indicated. In computer 101, the volatile memory 112 is located in a single package and is internal to computer 101, but, alternatively or additionally, the volatile memory may be distributed over multiple packages and/or located externally with respect to computer 101.
Persistent storage 113 is any form of non-volatile storage for computers that is now known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is being supplied to computer 101 and/or directly to persistent storage 113. Persistent storage 113 may be a read only memory (ROM), but typically at least a portion of the persistent storage allows writing of data, deletion of data and re-writing of data. Some familiar forms of persistent storage include magnetic disks and solid state storage devices. Operating system 122 may take several forms, such as various known proprietary operating systems or open source Portable Operating System Interface-type operating systems that employ a kernel. The code included in block 150 typically includes at least some of the computer code involved in performing the inventive methods.
Peripheral device set 114 includes the set of peripheral devices of computer 101. Data communication connections between the peripheral devices and the other components of computer 101 may be implemented in various ways, such as Bluetooth connections, Near-Field Communication (NFC) connections, connections made by cables (such as universal serial bus (USB) type cables), insertion-type connections (for example, secure digital (SD) card), connections made though local area communication networks and even connections made through wide area networks such as the internet. In various embodiments, UI device set 123 may include components such as a display screen, speaker, microphone, wearable devices (such as goggles and smart watches), keyboard, mouse, printer, touchpad, game controllers, and haptic devices. Storage 124 is external storage, such as an external hard drive, or insertable storage, such as an SD card. Storage 124 may be persistent and/or volatile. In some embodiments, storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where computer 101 is required to have a large amount of storage (for example, where computer 101 locally stores and manages a large database) then this storage may be provided by peripheral storage devices designed for storing very large amounts of data, such as a storage area network (SAN) that is shared by multiple, geographically distributed computers. IoT sensor set 125 is made up of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another sensor may be a motion detector.
Network module 115 is the collection of computer software, hardware, and firmware that allows computer 101 to communicate with other computers through WAN 102. Network module 115 may include hardware, such as modems or Wi-Fi signal transceivers, software for packetizing and/or de-packetizing data for communication network transmission, and/or web browser software for communicating data over the internet. In some embodiments, network control functions and network forwarding functions of network module 115 are performed on the same physical hardware device. In other embodiments (for example, embodiments that utilize software-defined networking (SDN)), the control functions and the forwarding functions of network module 115 are performed on physically separate devices, such that the control functions manage several different network hardware devices. Computer readable program instructions for performing the inventive methods can typically be downloaded to computer 101 from an external computer or external storage device through a network adapter card or network interface included in network module 115.
WAN 102 is any wide area network (for example, the internet) capable of communicating computer data over non-local distances by any technology for communicating computer data, now known or to be developed in the future. In some embodiments, the WAN 102 may be replaced and/or supplemented by local area networks (LANs) designed to communicate data between devices located in a local area, such as a Wi-Fi network. The WAN and/or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and edge servers.
End user device (EUD) 103 is any computer system that is used and controlled by an end user (for example, a customer of an enterprise that operates computer 101), and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives helpful and useful data from the operations of computer 101. For example, in a hypothetical case where computer 101 is designed to provide a recommendation to an end user, this recommendation would typically be communicated from network module 115 of computer 101 through WAN 102 to EUD 103. In this way, EUD 103 can display, or otherwise present, the recommendation to an end user. In some embodiments, EUD 103 may be a client device, such as thin client, heavy client, mainframe computer, desktop computer and so on.
Remote server 104 is any computer system that serves at least some data and/or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents the machine(s) that collect and store helpful and useful data for use by other computers, such as computer 101. For example, in a hypothetical case where computer 101 is designed and programmed to provide a recommendation based on historical data, then this historical data may be provided to computer 101 from remote database 130 of remote server 104.
Public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and/or other computer capabilities, especially data storage (cloud storage) and computing power, without direct active management by the user. Cloud computing typically leverages sharing of resources to achieve coherence and economies of scale. The direct and active management of the computing resources of public cloud 105 is performed by the computer hardware and/or software of cloud orchestration module 141. The computing resources provided by public cloud 105 are typically implemented by virtual computing environments that run on various computers making up the computers of host physical machine set 142, which is the universe of physical computers in and/or available to public cloud 105. The virtual computing environments (VCEs) typically take the form of virtual machines from virtual machine set 143 and/or containers from container set 144. It is understood that these VCEs may be stored as images and may be transferred among and between the various physical machine hosts, either as images or after instantiation of the VCE. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs and manages active instantiations of VCE deployments. Gateway 140 is the collection of computer software, hardware, and firmware that allows public cloud 105 to communicate through WAN 102.
Some further explanation of virtualized computing environments (VCEs) will now be provided. VCEs can be stored as “images.” A new active instance of the VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating-system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user-space instances, called containers. These isolated user-space instances typically behave as real computers from the point of view of programs running in them. A computer program running on an ordinary operating system can utilize all resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and devices assigned to the container, a feature which is known as containerization.
Private cloud 106 is similar to public cloud 105, except that the computing resources are only available for use by a single enterprise. While private cloud 106 is depicted as being in communication with WAN 102, in other embodiments a private cloud may be disconnected from the internet entirely and only accessible through a local/private network. A hybrid cloud is a composition of multiple clouds of different types (for example, private, community or public cloud types), often respectively implemented by different vendors. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technology that enables orchestration, management, and/or data/application portability between the multiple constituent clouds. In this embodiment, public cloud 105 and private cloud 106 are both part of a larger hybrid cloud.
The computing environment described above is only one example of a computing environment to incorporate, perform and/or use one or more aspects of the present invention. Other examples are possible. For instance, in one or more embodiments, one or more of the components/modules of
Further details relating to one or more components/modules of
One example of a storage area network is described with reference to an example schematic diagram depicted in
As examples, network devices 230 support the Fibre Channel (FC) and/or Fibre Channel over Ethernet (FCoE) protocols. For example, a particular fixed port network device may support the Fibre Channel protocol and/or the Fibre Channel over Ethernet protocol. Each network device 230 includes a plurality of ports that connect network devices 230 to various end devices 210, 220 via a plurality of links 225. In addition, each end device 210, 220 includes one or more ports that connect the end devices to one or more network devices 230 or to other end devices 210, 220. In one example, each link 225 is defined by the two ports that are connected to a link. The ports of end devices 220, 210 are referred to, in one example, as channel ports, while the ports of network device 230 are referred to, for instance, as switch ports.
Although the Fibre Channel (FC) and/or Fibre Channel over Ethernet (FCoE) protocols are specified herein, one or more of the network devices may support other protocols. Fibre Channel (FC) and/or Fibre Channel over Ethernet (FCoE) protocols are just examples.
The storage area network of
Another example of a storage area network is described with reference to
Referring to
Storage area network 300, as an example, is used to route data from a source (e.g., server 302) to a destination (e.g., storage device 304). In accordance with an aspect of the present invention, a routing toll is determined based on the route. For instance, each path (or selected paths) of, e.g., the network fabric (or, e.g., the storage area network) from one device to a next device in the route from the source to the destination has at least one toll value associated therewith and those toll values are used to determine the routing toll for the route. As one example, a toll value (e.g., weight, cost, selected value, attribute, etc.) is assigned to each network fabric connection of the route (or selected connections) and as the data traverses a connection, the associated toll value is applied (e.g., added, applied via, e.g., another mathematical operator, a mathematical equation or formula, or otherwise applied) to the routing toll defined for the data being routed. Based on the data being routed and the routing toll being determined, the determined routing toll may be used to determine a toll or cost for routing the data. As an example, if the routing toll is defined as a weight, then the total weight (i.e., the routing toll) may be converted into a toll or cost. For instance, a dollar value may be multiplied by the total weight to determine the toll. In a further example, each weight has a cost associated therewith and to determine the toll, each weight is multiplied by its associated cost to obtain intermediate results. The intermediate results are added to obtain a toll. Other examples are possible in which other operators, mathematical equations or formulas are applied to the weights and/or total weight to obtain the toll or cost. In another example, the routing toll is in terms of costs (e.g., a monetary value) and thus, the amount of the routing toll is the cost or toll. Other examples and variations are possible.
One example of determining a routing toll for a particular route is described with reference to
In another example, a toll value may be assigned to other components (in lieu of one or more connections or in addition to one or more connections) in a route from one device to another device. For instance, if a path from one device to a next device in a route includes a network appliance, as one example, a toll value for that network appliance may be assigned and included in the routing toll. As examples, the network appliance may be included along the path or be one of the devices coupled to a particular connection. Many variations are possible.
In one example, the data is packaged as a unit. For instance, the data is packaged in a packet that may be routed through the network. In one example, the packet is included in a frame and that frame is routed from the source through the network fabric (e.g., switched fabric 320) to the destination. The frame includes information used in the routing, and in accordance with an aspect of the present invention, includes information relating to tolling (e.g., the determining of costs associated with the routing).
One example of a frame used in accordance with one or more aspects of the present invention is described with reference to
Referring to
In one example, frame 400 includes a start-of-frame delimiter 402 to be used to indicate the start of a frame; one or more optional extended headers 404 used to provide selected information; a frame header 406 used to, e.g., control link operation, control device protocol transfers, and to detect missing frames or frames that are out of order; an optional network header 408 used to provide selected network information; an optional device header 410 used to provide selected device information; an optional tolling header 412, which, when included, is used to determine a routing toll for the packet, in accordance with one or more aspects of the present invention; a payload 414 which includes the data; one or more fill bits 416, as needed, to ensure the data field (which includes, e.g., the network header, if included; the device header, if included; the tolling header, if included; the payload; and the fill bits) is an integer multiple of, e.g., four bytes; a cyclic redundancy check (CRC) 418 to be used for integrity checking of fields within the frame; and an end-of-frame delimiter 420 to be used to specify the end of the frame. Further details relating to one or more headers used in accordance with one or more aspects of the present invention are described below.
For instance, frame header 406 includes one or more fields used to specify certain controls and/or the presence of optional headers used in routing the frame. As an example, in accordance with an aspect of the present invention and referring to
Based on tolling header indicator 432 specifying that a tolling header is included in the frame, the tolling header is used in determining tolls associated with traversing a network. In one example, referring to
Although one example of specifying the tolling header is described, in other examples, other frame formats and/or structures may be used to indicate the presence of a tolling header and/or include the tolling header. Many variations are possible.
Further details relating to using the tolling header are described with reference to
In one or more aspects, referring to
Example sub-modules of tolling module 150 include, for instance, an obtain packet sub-module 510 to be used to obtain a packet to be routed from a source to a destination; a tolling header inquiry sub-module 520 to be used to determine whether the packet has a tolling header; a tolling header creation/removal sub-module 530 to be used to create a tolling header and/or to remove a tolling header from a packet; a path determination/routing sub-module 540 to be used to determine one or more paths for the packet and to route the packet through a network; a cost determination sub-module 550 to be used to determine the cost of traversing a network; and an invoicing sub-model 560 to be used to provide an amount of the tolling. Although various sub-modules are described, a tolling module, such as tolling module 150, may include additional, fewer and/or different sub-modules. A particular sub-module may include additional code, including code of other sub-modules, or less code. Many variations are possible.
The sub-modules are used, in accordance with one or more aspects of the present invention, to determine a toll (e.g., a cost) associated with routing a packet from a source to a destination. Further, in one or more aspects, one or more of the sub-modules are used to determine a routing policy for a packet to be routed. The cost determination and routing policy are further described with reference to
As one example, a process 600 executing on a device (e.g., a network device, endpoint device) obtains (e.g., receives, is sent, is provided, retrieves, creates, etc.) 602 a packet sent to the device. Process 600 determines 604 whether the packet has a tolling header. If the packet does not have a tolling header, process 600 creates 606 a tolling header (e.g., tolling header 412), in accordance with one or more aspects, and initializes, e.g., a routing toll (e.g., routing toll field 442). In one example, it is initialized to zero. However, in other examples, it is initialized to other values. Further, in accordance with one or more aspects, process 600 determines 608 a routing policy setting for the packet. This determination is made based on, for instance, one or more policies, such as one or more invoicing policies for one or more selected entities, such as, for instance, an owner of the packet at the source device, an owner of the packet at the destination device and/or other selected entities. As an example, one invoicing policy may indicate that the fastest route is to be taken regardless of cost; another invoicing policy may be that the least expensive route is to be taken; another invoicing policy may be that the fastest route is to be taken during peak hours, but the least expensive route is to be taken during non-peak hours, etc. Many invoicing policies may be defined and used to determine routing policies. Those provided herein are just examples.
Based on determining the one or more routing policies for the packet, a routing policy indicator is set in the tolling header. For instance, routing policy field 440 of tolling header 412 is set to indicate the one or more selected routing policies. Based on the one or more routing policies indicated in the tolling header (either just created or in a previously created header), process 600 determines 610 a path to the next device in the route.
Process 600 determines 612 whether the next device is an endpoint. For instance, process 600 checks if the port being sent to next (i.e., the next device) is the destination port. (In other examples, other checks are made.) If the destination port is not next, then the next device is not an endpoint. Thus, process 600 determines 614 at least one toll value (e.g., a toll value for a connection, an appliance, and/or a device, etc.) for that path and applies that toll value to the routing toll. For instance, process 600 increments 616 a routing toll within, e.g., the tolling header (e.g., routing toll 442 of tolling header 412) by the at least one toll value. The packet is then sent 624 to the next device, and the processing is repeated (at, e.g., 602).
Returning to inquiry 612, if the next device is the endpoint (e.g., destination port is next), then process 600 creates 620 at least one invoice to be provided to one or more selected entities. This includes, for instance, including the routing toll (from, e.g., routing toll 442) or a portion of it in an invoice to be sent to the source device, the target device and/or other selected entities depending on the invoicing policies, and/or using the routing toll to determine the toll to be used to invoice the one or more selected entities. In one example, the toll is invoiced to one entity, such as the owner of the packet at the source device or the owner of the packet at the destination device. In another example, one portion of the toll is invoiced to one entity and another portion of the toll is invoiced to another entity. Further examples are also possible. The invoice(s) may be sent to the one or more selected entities using process 600 and/or one or more other processes.
Further, in one example, process 600 removes 622 the tolling header from the frame, and sends 624 the packet to the endpoint device.
As described herein, in one or more aspects, a tolling capability is provided in which, in one example, a packet enters a network, such as a storage area network, and is received by a device. Based on the device receiving the packet, the device looks up the invoicing policy of the source device (or one or more other selected entities), sets the routing policy indicator in the tolling header based on the device owner's policy, determines the route to the next device using the routing policy indicator, adjusts (e.g., increases) the routing toll in the tolling header based on at least one toll value of the route, and then sends the packet to the next device. If the next device is an endpoint device, the header is removed, and the routing toll is, e.g., added to the policy owner's bill, as an example.
One or more aspects of the present invention relate to computer technology and/or facilitating processing within a computer. By using a tolling header in a frame in routing a packet, appropriate policy and/or costs are determined facilitating use of Infrastructure as a Service. This facilitates processing relating to a processor, computer system and/or computing environment.
Although various embodiments are described herein, other aspects, variations and/or embodiments are possible. For instance, other types of network devices may be used including, but not limited to, routers, security appliances, network appliances with security features, analytic appliances, etc. Further, one or more of these and/or other network devices, devices and/or connections described herein may have a toll value assigned thereto, which contributes to the toll to be invoiced. Other variations are also possible.
The computing environments described herein are only examples of computing environments that can be used. Although various examples of computing environments are described herein, one or more aspects of the present invention may be used with many types of environments. The computing environments provided herein are only examples. Each computing environment is capable of being configured to include one or more aspects of the present invention. For instance, each may be configured to provide an automated tolling process and/or to perform to one or more other aspects of the present invention.
In addition to the above, one or more aspects may be provided, offered, deployed, managed, serviced, etc. by a service provider who offers management of customer environments. For instance, the service provider can create, maintain, support, etc. computer code and/or a computer infrastructure that performs one or more aspects for one or more customers. In return, the service provider may receive payment from the customer under a subscription and/or fee agreement, as examples. Additionally, or alternatively, the service provider may receive payment from the sale of advertising content to one or more third parties.
In one aspect, an application may be deployed for performing one or more embodiments. As one example, the deploying of an application comprises providing computer infrastructure operable to perform one or more embodiments.
As a further aspect, a computing infrastructure may be deployed comprising integrating computer readable code into a computing system, in which the code in combination with the computing system is capable of performing one or more embodiments.
As yet a further aspect, a process for integrating computing infrastructure comprising integrating computer readable code into a computer system may be provided. The computer system comprises a computer readable medium, in which the computer medium comprises one or more embodiments. The code in combination with the computer system is capable of performing one or more embodiments.
Although various embodiments are described above, these are only examples. For example, other mechanisms for tolling, in lieu of or in addition to using weights and/or costs for each connection or other components may be considered. Further, different types and/or configurations of frames and/or headers of frames may be used. Many variations are possible.
Various aspects and embodiments are described herein. Further, many variations are possible without departing from a spirit of aspects of the present invention. It should be noted that, unless otherwise inconsistent, each aspect or feature described and/or claimed herein, and variants thereof, may be combinable with any other aspect or feature.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising”, when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components and/or groups thereof.
The corresponding structures, materials, acts, and equivalents of all means or step plus function elements in the claims below, if any, are intended to include any structure, material, or act for performing the function in combination with other claimed elements as specifically claimed. The description of one or more embodiments has been presented for purposes of illustration and description but is not intended to be exhaustive or limited to in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain various aspects and the practical application, and to enable others of ordinary skill in the art to understand various embodiments with various modifications as are suited to the particular use contemplated.
| Number | Name | Date | Kind |
|---|---|---|---|
| 9197599 | Barry | Nov 2015 | B1 |
| 9336250 | Shaikh et al. | May 2016 | B1 |
| 9532161 | Raleigh | Dec 2016 | B2 |
| 9800639 | Gordon | Oct 2017 | B2 |
| 10356223 | Kuo et al. | Jul 2019 | B1 |
| 11196653 | Williams et al. | Dec 2021 | B2 |
| 20190012909 | Mintz | Jan 2019 | A1 |
| 20190228593 | Liu et al. | Jul 2019 | A1 |
| 20200234582 | Mintz | Jul 2020 | A1 |
| 20220319312 | Mintz | Oct 2022 | A1 |
| Entry |
|---|
| “Infrastructure as a Service (IaaS),” Portland State Computer Science, 2017 (no further date information available), pp. 1-39. |
| Anonymous, “Fully Decentralized Cloud using Generalized Trusted Execution Environments and Distributed Hash Tables (Without Blockchain),” IP.com No. IPCOM000264923D, Feb. 5, 2021, pp. 1-6 (+ cover). |
| Anonymous, “Infrastructure Resources Auto-Plan and Auto-Management Platform in Cloud Computing,” IP.com No. IPCOM000264627D, Jan. 14, 2021, pp. 1-2 (+ cover). |
| Anonymous, “Method and Apparatus for a Secure, Centralized Hybrid Multicloud Data Registry and Repository,” IP.com No. IPCOM000264374D, Dec. 8, 2020, pp. 1-4 (+ cover). |
| Anonymous, “Method of Storage Area Network (SAN) Notification of Storage Volume Degradation,” IP.com No. IPCOM000265618D, Apr. 29, 2021, pp. 1-5 (+ cover). |
| Obrutsky, Santiago Lucas, “Cloud Storage: Advantages, Disadvantages and Enterprise Solutions for Business,” Eastern Institute of Technology, Jul. 2016, pp. 1-9. |
| Sasongko, Hariyo et al., “Cloud-Based NAS (Network Attached Storage) Analysis as an Infrastructure as a Service (IAAS) Using Open Source NAS4FREE and Owncloud,” IT Journal Research and Development (ITJRD), vol. 6, No. 2, Mar. 2022, pp. 83-97. |
