Patent Application
20110191484
The present invention relates generally to the networking in computing devices, and more particularly to methods and devices for selecting network interfaces in multi-processor multimode network devices.
Historically, wireless communication devices, such as data cards, cellular telephones, wireless dongles, etc., have been built using a single processor which acts both as a modem and to provide processing power for user interfaces and applications. As a result, there has been no need to select a particular network interface to support an application since the basic architecture provided only a single alternative. However, as network speeds have increased, and as portfolios of applications available for execution on mobile computing devices have expanded, conventional architectures for managing network connections have become inefficient.
Most modern wireless communication devices now feature a separate applications processor. This separate application processor is required to handle the increased central processor unit computing requirements of advanced applications that are becoming increasingly popular for use on mobile multimedia computing devices, such as smart phones. Thus, wireless communication devices featuring an application processor and at least one modem processor are now quite common, such as smart phones, personal digital assistants (PDA), net books, etc.
As new wireless technologies continue to evolve, traditional wireless communication devices are expected to include various types of network technologies in order to support seamless user roaming and mobility across multiple communication networks. Different wireless technologies can be integrated in a number of different ways, including in multi-modem device architectures to enable faster development and product integration. Consequently, wireless communication devices are becoming increasingly complex in terms of number of modem processors and their various interconnections, which complicates the development of applications for use on such devices.
Embodiments include systems and methods for selecting a network connection for an application within a computing device. Various embodiments include a hierarchical procedure among several processors to select a best network interface in response to a network access request.
Further embodiments include a first or local processor receiving a network access request from an application and forwarding to the network access request to secondary or remote processors via a proxy interface. Each secondary or remote processor may select a network interface that best satisfies the network access request and return information on this network interface to the first processor. The first processor may evaluate its own interfaces and the interfaces selected by any secondary processors to determine a best network interface overall.
Further embodiments involve the secondary processors forwarding the network access request to tertiary processors. Tertiary processors, similar to the secondary processors, may select a network interface that best satisfies the network access request and return information on this network interface to the secondary processor(s). The secondary processors may consider the information returned from the tertiary in the secondary processor's selection process. This hierarchical selection process may be extended through multiple levels of processors.
Further embodiments may involve initiating a network configuration between the local processor and the selected best overall network interface. Connection setup may be initiated by an application or manager, or may be initiated automatically. The resulting data path between the local processor and the selected best network interface may be a chain of interfaces across multiple processors.
The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate exemplary embodiments of the invention, and together with the general description given above and the detailed description given below, serve to explain the features of the invention.
The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.
The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.
As used herein, the terms “mobile device” and “computing device” refer to any one or all of personal computers, laptop computers, cellular telephones, personal data assistants (PDA's), palm-top computers, wireless electronic mail receivers (e.g., the Blackberry® and Treo® devices), multimedia Internet enabled cellular telephones (e.g., the Blackberry Storm®), Global Positioning System (GPS) receivers, wireless gaming controllers, and similar personal electronic devices which include a programmable processor, memory, and one or more network interfaces.
As new wireless technologies continue to evolve, traditional wireless communication devices are expected to include various types of network technologies in order to support seamless user roaming and mobility across multiple communication networks. Different wireless technologies can be integrated in a number of different ways, including multi-modem device architectures to enable faster development and product integration. Consequently, wireless communication devices are becoming increasingly complex, which complicates the development of applications for use on such devices. Using current application design techniques and software architectures, application developers face a daunting task of keeping track of multiple modem interfaces that can provide an optimum connection for particular application networking requirements. Further, changes to the architecture of the computing device, such as the addition of new communications technologies or modems, may require extensive application rewriting and testing. This is especially true for networking applications which rely on different network technologies to provide a multitude of communication services for applications.
The complexity that is possible in modern and future computing devices is illustrated in
The various embodiments simplify the development of applications for current and future wireless communication devices, resolving the deficiencies of current methods described above, by providing a hierarchical routing layer which abstracts the actual proximity of the network connection. Using the various embodiments, an application can be configured so that it is able to request and receive a particular type of network connection without having to address or otherwise be concerned with the details of the actual connection established or the configuration of the computing device.
In the various embodiments, the hardware architecture and processor topology of the computing device is kept hidden from the applications. From the perspective of an application, an application can access a network connection using the same application programming interfaces (API) and assuming the same interface behavior as with current policy based network access routing methods, such as typical in single modem computing devices. From the perspective of the networking application, the application manages a network interface which connects to a specific network and reads/writes data into sockets associated with that network interface. A hierarchical routing layer is provided within the software architecture of each of the processors within the computing device (i.e., the application processor and the one or more modem processors).
The hierarchical routing layer abstracts the actual proximity of the network connectivity on the modem from the applications using proxy network interfaces. The hierarchical routing layers on each device processor cooperate to identify a best network interface for a particular application network request. The hierarchical routing layer also enables connection of an application request to a network interface in a simple manner regardless of whether the network interface is provided on the application host processor, another processor (e.g., a modem processor), or even on another processor via an intermediary processor.
A “proxy network interface” is an application that is located on the main application processor and represents a real network interface located on another processor. There can be one or more proxy interfaces, each representing a different real interface on a secondary processor. Typically, a proxy interface replicates the same Internet Protocol (IP) configuration and allows the same network operations as supported by the corresponding real network interface.
For ease of reference, the processor on which an application is executing is referred to herein as the “local processor” because the processor is local from the application's perspective. Thus, when a network interface is located on the same processor as the application, the network interface is said to be available on the local processor.
In the various embodiments, when an application requests a connection to a certain network type (e.g., communication network technology), the routing layer on the application processor performs a hierarchical interface selection procedure in order to select the best match interface for the application's needs. This interface selection procedure, which is described more fully below with reference to
The connection of the application to the selected best interface depends upon whether the selected interface is local or available on another processor. If this network connectivity is directly accessible from the local processor (i.e., the network interface is located on the same processor as the application), a handle to the real network interface is returned to the application. If the network connectivity is accessible from a different processor, i.e., the interface is located on a different processor, a handle to a proxy interface is returned to the application. This proxy interface represents and connects to the same physical network that the application originally requested, although the network connectivity is available on a remote processor. In other words, if the network is connected through a local processor, the application directly connects to the real network interface. However, if the network is connected through a remote processor, the application will connect to a proxy interface. In either case, the application is oblivious to the actual location of the network connectivity, and continues to use the network interface provided to it without necessarily knowing the proximity of the connection.
As is well known, processors may have two types of interfaces, an Rm type interface and an Um type interface. An Um type interface connects to a wireless network, such as a wireless WAN/LAN/MAN network which provides connectivity to the Internet or other local or global service domains. The Rm type interfaces are interfaces that connect to peripheral devices over different types of interconnections. Such Rm type interconnections may be serial wired connections, such as Universal Serial Bus (USB), Serial Peripheral Interface (SPI), Universal Asynchronous Receiver/Transmitter (UART), Secure Digital Input Output (SDIO), etc., serial wireless connections, such as a Bluetooth (BT) interface, or shared memory. The Rm type interface can also be used for other wireless connectivity, such as BT PAN and WiFi. Rm interfaces can be used to extend the network connectivity to a peripheral device, such as Universal Integrated Circuit Cards (UICC), laptops, other co-hosted processors, etc. Each Rm interface connects to a unique Um interface in order to obtain an IP configuration, although multiple Rm interfaces may be served by one Um type interface using Network Address Translation (NAT) or IP routing mechanisms. If an Um type interface is exclusively connected to an Rm type interface, the interfaces can be bridged together for efficient packet forwarding, rather than routing packets through the packet routing module.
Proxy interfaces may connect to Rm interfaces and, hence, pose as a peripheral device to the connecting modem processor. On the other side of the interface, the proxy interface may pose as an Um type interface serving an active and usable IP configuration. These proxy interfaces can be used directly by an application executing on the local processor, or by another peripheral device outside the local processor, such as a laptop or another modem. Hence, it is possible with the various embodiments to build a whole network of processor topology in the computing device. This processor topology can allow any number of peripheral devices to connect to any number of available modem processors in order to access different network technologies. The processor topology also enables any number of modem/application processors to be connected together in serial or parallel fashion. Thus, applications can run on any processor within the computing device (either modem processors or application processor), while having access to wireless networks accessible through remote processors.
Thus, the various embodiments enable applications to request and obtain network interfaces in any of the device architecture configurations shown in
Referring to
When an application on a local processor requests a network interface, the routing layer 22 on the local processor may implement a hierarchical routing algorithm to select a particular network interface to be returned to the application. The hierarchical routing algorithm may be implemented in the form of a hierarchical routing module (HRM) within the routing layer of each processor within the computing device. Example operations that may be executed within the hierarchical routing algorithm by an HRM in each of the processor routing layers are illustrated in
In a loop spanning steps 114 to 122, the local processor may obtain network interface suitability information from each connected processor that can be used to select a best interface for the application. Specifically, in step 114, the local processor may select one (x) of the available directly connected processors for evaluation. In step 116, the local processor may forward the interface selection request, including all of the network selection policy parameters, to the selected processor x via one (g) of the proxy interfaces in {Ipx}. The selected proxy interface may be any interface that is currently available (i.e., the proxy interface may be randomly selected from the set {Ipx}). If there are no processors coupled to the local processor, (i.e., the list of available processors {Pr} is a null set), steps 116 and 118 will be skipped. In step 118, the local processor will receive back from the selected processor x information regarding the interface best matching the network selection policy parameters available on that processor. This information may include: a best match interface Mi which is an interface identifier that is mapped to the corresponding proxy interface Mpi (which is one of the interfaces among the set {Ipx}); and a match index I, which may be an integer value indicating how well the network interface can support the requested network policy. In an embodiment, the better the identified network interface matches the network selection policy parameters, the higher the value of the match index I. Providing a match index value facilitates identifying an available network interface among a plurality of network interfaces available through a plurality of modem processors that best matches the application's network policy parameters under the existing network conditions.
The information reported back to the local processor in step 118 may be generated by the selected processor x in a similar routing layer routing algorithm, as described below with reference to
In determination step 122, the local processor determines whether the selected processor is the last processor within the list {Pr}. If there is another processor to evaluate (i.e., determination step 122=“No”), the processor may return to step 114 to select the next processor x within the list {Pr}.
If all processors have been evaluated (i.e., determination step 122=“Yes”), the processor may evaluate each real interface (i.e., the interfaces available in the local processor in list {Ir}) in a loop spanning steps 124 to 130. Specifically, in step 124, the local processor may select one (h) interface within the list {Ir} of real interfaces connected to the local processor. In step 126, the network selection policy parameters are evaluated against the selected interface h characteristics to determine a match index I value for the selected interface. The evaluation of local interfaces against the desired network capabilities and network policy parameters can be accomplished using any of a variety of methods well known to one of skill in the art. Information regarding the degree to which a local interface satisfies the interface selection request may be stored in a four-tupple [0, Null, h, I] value. This four-tupple [0, Null, h, I] indicates that the local processor (indicated by the value “0”) can support the desired network connectivity with a real interface h that has a match index value of I. In determination step 130, the local processor determines whether the selected local interface h is the last local interface within the list {Ir}. If there is another local interface to evaluate (i.e., determination step 130=“No”), the processor may return to step 124 to select the next local interface h within the list {Ir}.
If all local interfaces have been evaluated (i.e., determination step 130=“Yes”), local processor evaluates the stored four-tupple values to identify the interface with the highest match index I which is selected for use in step 132. Information within the four-tupple of the selected interface is recalled from memory as part of step 132.
In determination step 134, the local processor determines whether the selected interface is a remote or local interface, such as by determining whether the processor ID (i.e., the first value in the four-tupple) is equal to “0” which indicates that the selected interface is local. If the selected interface is a local interface (i.e., determination step 134=“Yes”), the network configuration of the selected interface is initiated in the network defined manner in step 136.
If the selected interface is a remote interface (i.e., determination step 134=“No” and the processor ID is a value other than “0”), the proxy interface Mpi is configured to associate with the remote processor in step 138. This configuration of the proxy interface Mpi may be accomplished by configuring the proxy interface and establishing a connection to the selected interface of the remote processor (i.e. the remote modem).
Various embodiments may implement different methods for initiating the connection setup between the proxy interface Mpi and the selected interface Mi in step 138. In a first method, an application or connection manager may initiate the connection setup. Based on a selected interface Mi returned by the hierarchical routing module (HRM), the application or connection manager may issue a network connect request. Configuration of the interface may happen as part of this process. In a second method, the connection setup may occur automatically as soon as the best match interface is available or based on another triggering event. Configuration of the interface then happens after that.
In both cases, the connection setup and configuration process may proceed in step 138 as further illustrated in
As illustrated in
The same basic hierarchical routing algorithm may be implemented on each processor in a routing layer. This embodiment will support an arbitrary network of processors connected to together in a computer architecture and allow applications running on any one of the processors to access any network via any modem. Thus, when a network selection request is forwarded to the next processor in step 114, the same basic algorithm is executed again over the set of local and proxy interfaces on that next (i.e. remote) processor. The interface selection request will arrive over an Rm link connected to the proxy interface g. The Rm interface will forward the request to the routing layer and invoke the hierarchical routing algorithm. From the Rm interface perspective, this process is how the interface supports peripheral connectivity in single modem devices (e.g.,
Since applications may run on any processor within a computing device architecture, such as the computer architectures illustrated in
Referring to
In a loop spanning steps 214 to 222, the remote processor may obtain network interface suitability information from each connected doubly remote processor that can be used to select a best interface for responding to the interface selection request. Specifically, in step 214, the remote processor may select one (x) of the available directly connected doubly remote processors for evaluation for receiving interface suitability information. In step 216, the remote processor may forward the interface selection request, including all of the network selection policy parameters, to the selected doubly remote processor x via one (g) of the proxy interfaces in {Ipx}. The selected proxy interface may be any interface that is currently available (i.e., the proxy interface may be randomly selected from the set {Ipx}). If there are no doubly remote processors coupled to the remote processor, i.e., the list of available processors {Pr} is a null set, step 216 will be skipped. In step 218, the remote processor will receive back from the selected doubly remote processor x information regarding the interface best matching the network selection policy parameters available on that processor. This information may include: a best match interface Mi which is an interface identifier that is mapped to the corresponding proxy interface Mpi (which is one of the interfaces among the set {Ipx}); and a match index I, which may be an integer value indicating how well the network interface can support the requested network policy. The information reported back to the remote processor step 218 may be stored by the remote processor routing layer as a four-tupple [x, Mpi, Mi, I] in step 220. In determination step 222, the remote processor determines whether the selected doubly remote processor is the last processor within the list {Pr}. If there is another doubly remote processor to evaluate (i.e., determination step 222=“No”), the processor may return to step 214 to select the next processor x within the list {Pr}.
If all doubly remote processors have been evaluated (i.e., determination step 222=“Yes”), the remote processor may evaluate each real interface (i.e., the interfaces available in the remote processor in list {Ir}) in a loop spanning steps 224 to 230. Specifically, in step 224, the remote processor may select one (h) interface within the list {Ir} of real interfaces connected to the remote processor. In step 226, the network selection policy parameters are evaluated against the selected interface h characteristics to determine a match index I value for the selected interface. The evaluation of local interfaces against the desired network capabilities and network policy parameters can be accomplished using any of a variety of methods well known to one of skill in the art. Information regarding how well a local interface satisfies the interface selection request may be stored in a four-tupple [0, Null, h, I] value. This four-tupple [0, Null, h, I] indicates that the remote processor (indicated by the value “0”) can support the desired network connectivity with a real interface h that as a match index value of I.
In determination step 230, the remote processor determines whether the selected local interface h is the last local interface within the list {Ir}. If there is another local interface to evaluate (i.e., determination step 230=“No”), the remote processor may return to step 224 to select the next local interface h within the list {Ir}.
When all local interfaces have been evaluated (i.e., determination step 230=“Yes”), the remote processor evaluates the stored four-tupple values to identify the interface with the highest match index I which is selected in step 232. In step 234, the remote processor returns to the local processor (i.e., the processor that issued the interface selection request) the interface selection information, including the proxy interface identifier Mpi and the interface match index I. If the selected interface is local (i.e., on the remote processor), the interface identifier h is returned as the proxy interface identifier Mpi.
By implementing the various embodiments in a distributed hierarchical decision making architecture using similar routing layer modules on all processor within or connected to the computing device as described above, the various embodiments can be employed with computing devices that have any number of different layers of processors. Further, applications written for one computing device architecture may be implemented on computing devices with much more complex multiprocessor architectures without the need for changes to the code or testing for configuration compatibility. Additionally, the various embodiments operate the same regardless of which processor hosts the application which issues the network connection request.
The various embodiment procedures are hierarchical and can span all processors within a computer's architecture. In general, the hierarchical routing algorithm allows for the device topology to be represented as a tree like structure as illustrated in
The various embodiments support implementations in which applications may be running on various modem processors, and not on a main application processor. This may occur for a number of reasons. For one, an application may have been developed and tested for a specific modem processor which is now connected to an application processor. When other processors have been added over time to support additional network connectivity, enabling the application to continue to run on the specific modem processor may avoid the need to reintegrate existing applications on new processor environments. Additionally, specific radio functionality may be only available on certain modem processors, or the more optimally accessible through a particular modem processor. Further, system applications that need to run on the modem processor for interface management and configuration may be hosted on the modem's processor rather than the application processor.
In certain scenarios, applications running on modem processors may desire to use radio connectivity provided by other modem processors. The hierarchical routing algorithms of the various embodiments can be used to solve such scenarios. As shown in
By implementing the embodiments in a hierarchical decision-making architecture, each processor within the computing device can make its own determination of a local best connected interface for the requested network connection, and relay its local best connection characteristics to the application making the request or processor forwarding the request (i.e., the next higher layer processor). This distributed decision-making may be explained by way of an example with reference to
The configuration and setup of a data path may also follow a hierarchical approach. For example, again with reference to
Additionally, interface chains may be established in a similar manner in a reverse direction from one requesting processor to another processor having a real interface to a desired network or resource. Thus, a second processor in one chain of interfaces may establish a proxy interface connection with a third processor that may already have a different proxy interface connection established with the second processor as part of a second chain of interfaces. In such a situation both proxy interface connections between the second and third processors may be established using the same operations as described above with reference to
The embodiments can be applied to a vast array of computing architectures and application scenarios, and thus are not limited to the foregoing descriptions of example embodiments. Further, the number of proxy interfaces and real (Rm) interfaces that need to be supported in each processor will vary from system to system, and can be statically or dynamically configured. In one embodiment, a static configuration table may be input to the modem during the boot-up process, and the modem processor can create a desired number of interfaces based on such configuration information. In an alternative embodiment, Rm interfaces can be created on an as-needed basis dynamically. Proxy and Um interfaces are typically created up front to represent all of the possible connectivity options available in the particular computer device.
Even though applications are oblivious to the proximity the network connections, applications may observe additional delays if the connections span multiple processors. To accommodate this, embodiments may minimize the impact by reducing the inter-processor communication delays as much as possible.
To support the various embodiments, a signaling mechanism or signaling channel is required to support communication between the various hierarchical routing modules or routing layers of the different processors for transmitting interface selection request and receiving back the results. Any suitable signaling mechanism or signaling channel can be used for this purpose, such as the QMI messaging protocol. It should be noted that the signaling mechanism may be accomplished over the same physical interconnect, with signaling occurring via the signaling mechanism and data transmissions via IP traffic, as is provided in USB interfaces.
The various embodiment procedures described herein should function irrespective of the types of interconnections used between different processors, which can vary within the same computing device. Thus, the embodiments are not tied or limited to any particular computing architecture, inter-processor communication protocol or connection, or wireless communication technology.
In a further embodiment, the best interface selection decision or interface match index values and four-tupples may be stored in memory of the application processor 10 in order to support subsequent application network access requests. This embodiment may be useful to save processing time when no changes to device configuration, network characteristics or network selection policy parameters have occurred since a last time the hierarchical routing algorithm was accomplished. In this embodiment, the application processor may compare the network selection policy parameters to parameters from a previously completed network selection to determine if they are the same, and configure a network connection according to a stored selected interface configuration information.
Typical mobile devices 300 suitable for use with the various embodiments will have in common the components illustrated in
The various aspects of the present invention described above may be implemented on any of a variety of mobile computing devices, such as a laptop computer 400. Typically, such computing devices will have in common the components illustrated in
The various processors 301, 310, 312, 314, 316, 401 may be any programmable microprocessor, microcomputer or multiple processor chip or chips that can be configured by software instructions (applications) to perform a variety of functions, including the functions of the various embodiments described herein. In some mobile devices, multiple processors 301, 310, 312, 314, 316, 401 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to running other applications. Typically, software applications may be stored in the internal memory 302, 402 before they are accessed and loaded into the processor 301. In some mobile devices, the processor 301, 310, 312, 314, 316, 401 may include internal memory sufficient to store the application software instructions. In many computing devices 300, 400, the internal memory 302, 402 may be a volatile or nonvolatile memory, such as flash memory, or a mixture of both. For the purposes of this description, a general reference to memory refers to all memory accessible by the processor 301, 310, 312, 314, 316, 401, including internal memory 302, 402 removable memory plugged into the wireless receiver 300, 400, and memory within the processor 301, 310, 312, 314, 316, 401 itself.
The various embodiments provide a number of benefits for computing devices. Any computer architecture or processor apology can be supported using a single distributed implementation of the hierarchical routing algorithm. Applications may reside on any processor within the computing device, and may be able to access networks via any other processor without requiring the application to know the proximity of the network radio. Existing applications do not need to be changed, rewritten or reintegrated in order to adapt to new emerging network technologies and computing device architectures. Device manufacturers can add additional network capabilities by adding new modems without significantly impacting existing network and communication applications. Processors from different manufacturers can be combined and joined together for faster device integration and quicker time-to-market implementation of new communication technologies. All of these benefits are in addition to the significant savings in application development time enabled by freeing the application developer from having to keep track of and manage network interfaces within a complex computing device.
The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the order of steps in the foregoing embodiments may be performed in any order. Words such as “thereafter,” “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.
The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.
In one or more exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in hardware, the functionality may be implemented within circuitry of a wireless signal processing circuit that may be suitable for use in a wireless receiver/transceiver or mobile device. Such a wireless signal processing circuit may include circuits for accomplishing the signal measuring and calculating steps described in the various embodiments. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a processor-readable medium. The steps of a method or algorithm disclosed herein may be embodied in a processor-executable software module which may reside on a processor-readable storage medium. A storage media may be any available tangible storage media that may be accessed by a processor or computer. By way of example, and not limitation, such processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a processor or computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a machine readable storage medium and/or processor-readable storage medium, which may be incorporated into a computer program product.
The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.
This application claims the benefit of priority to U.S. Provisional Patent Application 61/297,338 entitled “Hierarchical Routing and Interface Selection for Multi-processor Multimode Network Devices” filed Jan. 22, 2010, the entire contents of which are hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 61297338 | Jan 2010 | US |
