Patent Document

FIELD OF THE INVENTION 
       [0001]    The present application relates generally to handling streams of traffic generated by applications and, more specifically, to a network-aware adapter for communicating the streams to intelligent network components. 
       BACKGROUND OF THE INVENTION 
       [0002]    Applications executed at the application layer of a networked device have traditionally communicated over the network to which the networked device is connected through a simple Media Access Control (MAC) layer. Furthermore, as MAC layers differ for different networking protocols (i.e., different transmission media), applications have been developed taking into consideration specifics of the MAC layer for the particular networking protocol in use in the network to which the device to be connected. 
         [0003]    MAC layers associated with newer networking protocols have added complexity that allow an application to specify a Quality of Service (QoS) desired for a particular stream of data traffic that is generated by the application. Often a simple MAC layer lacks the complexity that allows an application to specify a QoS desired for a particular stream of data traffic. Consequently, most applications have not been provided with, or have not been required to have, a degree of intelligence necessary to fully utilize network technology underlying transmissions from the applications. 
         [0004]    Such applications, by not having a degree of intelligence, cannot fully take advantage of QoS functions embedded in some new networking technologies, such as WiMAX, nor address some of the unique technical challenges of such new networking technologies. Unfortunately, when the degree of intelligence necessary to take advantage of new networking technologies is built in to new applications, the complexity of the devices designed to execute the new application is increased. Accordingly, the added complexity may drive up the cost of the devices and may push the physical bounds of Application Specific Integrated Circuit technology. 
       SUMMARY 
       [0005]    Streams of data traffic may be handled by a network-aware adapter module as part of a greater platform for filtering communicating the streams to intelligent network components. A distinguishing factor associated with a given data stream may be determined and used as a basis for selecting a QoS Policy setting for the given data stream. The selected QoS Policy setting may then be signaled to a media access control layer. 
         [0006]    In accordance with an aspect of the present invention there is provided a method of adapting a data stream before the data stream proceeds to a media access control (MAC) layer, the MAC layer having been adapted to receive QoS Policy settings. The method includes receiving a packet, where the packet is associated with a data stream, determining a distinguishing factor associated with the data stream, selecting, based on the distinguishing factor, a QoS Policy setting for the data stream and signaling the QoS Policy setting to the MAC layer in association with the packet. In other aspects of the present invention, a computing device is provided for carrying out this method and a computer readable medium is provided for adapting a processor to carry out this method. 
         [0007]    Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the invention in conjunction with the accompanying figures. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]    Reference will now be made to the drawings, which show by way of example, embodiments of the invention, and in which: 
           [0009]      FIG. 1  illustrates interconnection of components of a computing device that may be connected to a data communication network; 
           [0010]      FIG. 2  illustrates a logical structure for communication employing Windows Management Instrumentation; 
           [0011]      FIG. 3  illustrates a logical structure for communication employing a Windows Filtering Platform; 
           [0012]      FIG. 4  illustrates a Windows Filtering Platform including a network-aware adapter, a filter engine and a QoS manager in accordance with aspects of the present invention; 
           [0013]      FIG. 5  illustrates steps in an example method of operation of the filter engine of  FIG. 4  in accordance with an aspect of the present invention; 
           [0014]      FIG. 6  illustrates steps in an example method of operation of the QoS manager of  FIG. 4  in accordance with an aspect of the present invention; and 
           [0015]      FIG. 7  illustrates steps in an example method of operation of the network-aware adapter of  FIG. 4  in accordance with an aspect of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE EMBODIMENTS 
       [0016]      FIG. 1  illustrates interconnection of components of a computing device  100  that may be connected, in a wired manner or a wireless manner, to a data communication network  108 . The illustrated components of the computing device  100  include a microprocessor  116  and, connected to the microprocessor  116 , a storage device  120 , a random access memory (RAM)  118  and a network interface card (NIC)  104 . The NIC  104  allows for connection of the computing device  100  to the data communication network  108 . 
         [0017]    The microprocessor  116  operates under stored program control with code being stored in the storage device  120 . As depicted in  FIG. 1 , while operational, the RAM  118  stores programs including an operating system program or code module  136 , such as for the known Microsoft Windows™ operating system. Operating systems such as Windows typically divide the RAM  118  space into two portions, namely a user space  140  and a restricted access space, such as a kernel space  138  or functional equivalents thereof. The RAM  118  further stores software applications, indicated generally by reference  142 , that typically reside in the user space  140 , and drivers  144 , which typically reside in the kernel space  138 . 
         [0018]      FIG. 2  illustrates a logical structure for communication employing Windows Management Instrumentation (WMI), where the communication is between an application  202  and the NIC  104 . WMI is a set of extensions to the known Windows Driver Model that provides an operating system interface through which instrumented components provide information and notification. WMI is a Microsoft implementation of the Web-Based Enterprise Management (WBEM) standard and the Common Information Model (CIM) standard from the Distributed Management Task Force (DMTF). 
         [0019]    The NIC  104  requires a driver  206 , selected from among the drivers  144  of  FIG. 1 . The driver  206 , which includes the MAC layer, communicates with a Network Driver Interface Specification (NDIS) driver  208 , which is in the kernel space. The NDIS driver  208  implements an API for NICs that was jointly developed by Microsoft and 3Com Corporation. The NDIS is a Logical Link Control (LLC) that forms the upper sublayer of the OSI data link layer (layer 2 of 7) and acts as an interface between the OSI data link layer the Network Layer (layer 3 of 7). The lower sublayer is the MAC device driver. The NDIS is a library of functions often referred to as a “wrapper” that hides the underlying complexity of the hardware of the NIC  104  and serves as a standard interface for level 3 network protocol drivers and hardware-level MAC drivers. 
         [0020]    The NDIS driver  208  communicates with a WMI module  210 , which is also in the kernel space. The WMI module  210  communicates with a WMI API  212  in the user space. The WMI API  212  communicates with the application  202 . 
         [0021]      FIG. 3  illustrates a logical structure for communication employing a Windows Filtering Platform, where the communication is between an application  302  and the NIC  104 . 
         [0022]    In common with the structure employing WMI as illustrated in  FIG. 2 , the structure employing WFP as illustrated in  FIG. 3  includes the NIC  104  in communication with the driver  206 . The driver  206 , in turn, communicates with the NDIS driver  208 . Distinct from the WMI case of  FIG. 1 , the NDIS driver  208  communicates with a Windows Filtering Platform (WFP)  310 . The WFP  310  straddles the kernel space  138  and the user space  140  and communicates with a WFP API  312  in the user space  140 . The WFP API  312  communicates with the application  302 . 
         [0023]    There is a WFP API included in the Vista™ version of the Microsoft Windows operating system. The WFP API allows applications to tie into the packet processing and filtering pipeline of the new network stack in Windows Vista and Windows Server 2008. The WFP provides features that include integrated communication. Furthermore, the WFP can be configured to invoke processing logic on a per-application basis. 
         [0024]    When the network to which the computing device  100  connects is a Transport Communication Protocol (TCP) and Internet protocol (IP) network, the network stack  440  may be called a TCP/IP stack. 
         [0025]    In view of  FIG. 4 , the WFP  310  may be implemented as a filtering engine, a network stack  440  and a set of callout modules. The network stack  440  may comprise a plurality of “shims”. Shims expose internal structures of a packet as properties. Different shims exist for protocols at different layers. In operation, the filtering engine compares the data in received packets against a specified set of rules. The WFP  310  is considered to, by default, include an in-built set of shims. Furthermore, shims for other protocols can be registered with the filtering engine using the WFP API  312 . The in-built set of shims include: an Application Layer Enforcement (ALE) shim  404 ; a Stream shim  408 ; Transport Layer Module (TLM) shim  410 ; and a Network Layer Module (NLM) shim  414 . Registered shims illustrated in  FIG. 4  include: a Transport Driver Interface Winsock Kernel (TDI WSK) shim  406 ; a forwarding layer shim  412 ; and an NDIS layer shim  416 . 
         [0026]    The filtering engine, which provides basic filtering capabilities, spans across both the kernel space  138  and the user space  140 . As identified in  FIG. 4 , a portion of the filtering engine resident in the kernel space  138  is referred to as a “filter engine”  402  and a portion of the filtering engine resident in the user space  140  is referred to as a “base filtering engine”  418 . 
         [0027]    The filtering engine matches data in a given packet, which data has been exposed by the shims, against filtering rules. Based on a match between the data and one or more rules, the filtering engine may either permit the given packet to pass through or prevent the given packet from passing through. If another action is necessary, the other action can be implemented through the use of a callout module. The filtering rules are applied on a per-application basis. 
         [0028]    The base filtering engine  418  is a module that manages the filtering engine. The base filtering engine  418  accepts filtering rules and enforces a security model specific to an application. The base filtering engine  418  also maintains statistics for the WFP  310  and maintains a log of the state of the WFP  310 . 
         [0029]    A callout module is a callback function exposed by a filtering driver. The filtering drivers are used to provide filtering capabilities other than the default filtering capability in which packets are either block or permitted to pass through. During registration of a filter rule, a callout module may be specified. When a packet is received having data that matches the filter rule, the filter engine  402  invokes, via a set of callout APIs  420 , an associated callout module. The associated callout module then executes some specific filtering capability. 
         [0030]    A callout module, which can be registered at all layers, extends the capabilities of the WFP  310 . Each callout module has a unique globally unique identifier (GUID). Callout modules may be used for Deep Inspection, i.e., performing complex inspection of network data to determine which data is to be: blocked; permitted; or passed to another filter. Callout modules may be used for Packet Modification, which may include modification of the header or payload of a packet that is received as part of a stream and injection of the modified packet back into the stream. Other uses of callout modules include Stream Modification and Data Logging. 
         [0031]    Example callout modules illustrated in  FIG. 4  include an anti-virus callout module  422 , a parental control callout module  424 , an Intrusion Detection System (IDS) callout module  426  and a Network Address Translation (NAT) callout module  428 . 
         [0032]    In the user space  140  the base filtering engine  418  communicates with the WFP API  312 , which, in turn, communicates with applications such as the application  302 , an operating system-based firewall  450  and an other application  452  (which may be a further firewall). The WFP API  312  is also in communication with a QoS manager  432 , for implementing aspects of the present invention. 
         [0033]    In overview, the QoS manager  432  configures the network-aware adapter callout module  430  to prioritize streams from the application  302 , the OS-based firewall  450  and the other application  452 . As will be clear to a person of ordinary skill in the art, the applications  302 ,  450 ,  452  illustrated in  FIG. 4  are merely examples and there may be more or fewer or different applications as required by the computing device  100  ( FIG. 1 ). 
         [0034]    In carrying out the prioritization, the network-aware adapter callout module  430  interacts with the MAC layer (not shown) in the driver  206 . Additionally, the network-aware adapter callout module  430  interacts with the applications  302 ,  450 ,  452  and with policy. As will be clear to a person of ordinary skill in the art, various policies regarding handling of streams from the applications  302 ,  450 ,  452  may be received, by the computing device  100 , from a central directory. 
         [0035]    The role of the adapter callout module  430  is to make intelligent use of signaling to achieve end-to-end QoS through the use of policies and/or service characterizations. The network-aware adapter callout module  430  can further: manage QoS and spectrum efficiency trade offs; manage terminal operation responses and power reservation tradeoffs; and manage other network intelligence that can be embedded, such as Location Based Services (LBS) and Multicast Broadcast Services (MBS). 
         [0036]    In operation, the filter engine  402  is structured as a set of layers of filters, with each layer having an associated priority. A given stream can be blocked even if a higher priority filter has permitted the given stream. The filter structure allows multiple actions to be performed on the same stream. The layers in the filter engine  402  are divided into sub-layers. Within a sub-layer filters are evaluated in weight order. Evaluation stops at first match (permit/block). When a match occurs between a stream and a filter, a related callout module is notified. If the notified callout returns continue, the next matching filter is evaluated. Notably, streams are evaluated at each sub-layer. 
         [0037]    In operation, in relation to a stream forthcoming from the application  302 , the QoS manager  432  transmits an instruction to the filter engine  402  to initialize a callout driver for the network-aware adapter callout module  430 . In particular, the instruction may specify an unload function. Upon receiving (step  502 ,  FIG. 5 ) the instruction to initialize the callout driver, the filter engine  402  may create a device object and register the network-aware adapter callout module  430 . 
         [0038]    Operation of the QoS manager  432  may be further considered in view of  FIG. 6 . Initially, the QoS manager  432  opens a session (step  602 ) to the filter engine  402 . The QoS manager  432  then instructs the filter engine  402  to add a sub-layer (step  604 ) to the structure of the filter engine  402  and instructs the filter engine  402  to add a filter (step  606 ) to the just-added sub-layer. 
         [0039]    Responsive to receiving the instruction to add the filter in step  606 , the filter engine  402  may add the requested filter and may process a notify function (step  504 ,  FIG. 5 ), commonly called “Notifyfn( )”, to indicate the addition of the filter to the network-aware adapter callout module  430 . 
         [0040]    As packets of the stream coming from the application  302  for which the filter has been established arrive in the network stack  440 , the packets are processed by the filter engine  402 . 
         [0041]    In particular, the filter engine  402  may process a classify function (step  506 ,  FIG. 5 ), commonly called “Classifyfn( )”, to indicate, to the network-aware adapter callout module  430 , the arrival, in the network stack  440 , of the packets of the stream coming from the application  302  for which the filter has been established. 
         [0042]      FIG. 7  illustrates steps in an example method of adapting the stream at the network-aware adapter callout module  430 . 
         [0043]    In particular, the network-aware adapter callout module  430  initially receives (step  702 ) a packet of the stream and determines (step  704 ) a distinguishing factor associated with the stream. Subsequently, the network-aware adapter callout module  430  selects (step  706 ), based on the distinguishing factor, a QoS Policy setting for the data stream. Finally, the network-aware adapter callout module  430  modifies the stream data to signal (step  708 ) the selected QoS Policy setting to the MAC layer (not shown) in the driver  206 . 
         [0044]    At the packet level, to modify the stream data to signal (step  708 ) the selected QoS Policy setting to the MAC layer, the network-aware adapter callout module  430  may make a clone of the packet received in step  702 . The network-aware adapter callout module  430  may then modify the clone to form a modified clone, where the modified clone incorporates a signal representative of the selected QoS Policy. The network-aware adapter callout module  430  may then inject the clone, using Classifyfn( ), into the network stack  440 . 
         [0045]    The term “QoS Policy setting” is used herein to be more encompassing than the known term “Quality of Service”. The term Quality of Service is known to include settings for bit rate, delay, jitter and packet error rate. In addition to these settings, the term “QoS Policy setting” is used herein to further include user priority or user group priority, etc. 
         [0046]    The distinguishing factor may be, for instance, an identification of the application  302  that is the origin of the stream, an identification of a subscriber associated with the stream or an identification of a media type for the data within the stream. 
         [0047]    Where the data stream is a stream of a plurality of Internet Protocol (IP) packets, the determining the distinguishing factor (step  704 ) may involve inspecting a header field in a given packet among the plurality of IP packets. In which case, the distinguishing factor may be, for instance, a source IP address, a destination IP address, a source port or a destination port. 
         [0048]    Where the distinguishing factor is the identity of the application  302 , the selection (step  706 ,  FIG. 7 ) of the QoS Policy setting may be based on a priority level associated with the application  302 . Additionally, the identity of the application  302  may be associated with a type of application and the selection (step  706 ,  FIG. 7 ) of the QoS Policy setting may be based on the type associated with the application  302 . Example application types include video, voice, gaming, collaboration and instant messaging. 
         [0049]    The distinguishing factor may be, for instance, an identification of a subscriber associated with the application  302  that is the origin of the stream. 
         [0050]    Alternatively, the distinguishing factor may be, for instance, an identification of the media type of the link between the network interface card  104  and the data communication network  108  (see  FIG. 1 ). The media type may be defined as, for instance, wired Ethernet as defined by the Institute for Electrical and Electronics Engineers (IEEE) standards related to IEEE 802.3, such as: 10 Megabit per second Ethernet; Fast Ethernet; Gigabit Ethernet; or 10 Gigabit Ethernet. 
         [0051]    Additionally, the media type may be defined as, for instance, “WiFi”, meaning wireless networking as defined by the Institute for Electrical and Electronics Engineers (IEEE) standards such as: IEEE 802.11a, IEEE 802.11b, IEEE 802.11g or IEEE 802.11n. 
         [0052]    Furthermore, the media type may be defined as, for instance, “WiMAX” for Worldwide Interoperability for Microwave Access, meaning wireless networking as defined by the IEEE 802.16-2004 standard and the IEEE 802.16e-2004 amendment. 
         [0053]    The media type may also be defined as, for instance, “Long Term Evolution (LTE)”. Long Term Evolution is the name given to a project within the Third Generation Partnership Project (3GPP, see www.3gpp.org) to improve the Universal Mobile Telecommunications System mobile phone standard, which is also maintained by 3GPP, to cope with future requirements. 
         [0054]    When the stream being processed by the filter engine  402  and the network-aware adapter callout module  430  is terminated, the filter engine  402  processes a Flow Delete function (step  508 ,  FIG. 5 ), commonly called “Flowdeletefn( )”, to indicate, to the network-aware adapter callout module  430 , that the stream has terminated. 
         [0055]    Furthermore, the QoS manager  432  may delete (step  608 ,  FIG. 6 ) the filter. 
         [0056]    Responsive to the deletion of the filter in step  608 , the filter engine  402  may process the notify function to indicate the deletion of the filter to the network-aware adapter callout module  430 . 
         [0057]    Additionally, the QoS manager  432  may delete (step  610 ,  FIG. 6 ) the sublayer and close (step  612 ) the session opened in step  602 . Responsive to the closing of the session, the filter engine  402  may unload (step  510 ,  FIG. 5 ) the callout driver. 
         [0058]    In operation of the computing device  100 , a user may employ a user interface to select an application to execute. The computing device  100  may be, for instance, a portable (i.e., notebook) computer and the selected application may be a video transmission application. Furthermore, the connection between the network interface card  104  and the data communication network  108  may be a WiMAX connection. Accordingly, the MAC layer in the driver  206  is a WiMAX MAC layer. The WiMAX MAC layer is known to accept specification of QoS parameters. The QoS manager  432  configure a filter in the filter engine  402  to send packets in the stream from the video transmission application to the network-aware adapter  430 . Furthermore, the network-aware adapter  430 , upon determining that the data in the stream is video, selects a 200 kilobit per second bandwidth and modifies the packets in the stream to signal to the WiMAX MAC layer that the stream should receive a 200 kilobit per second bandwidth. 
         [0059]    At the WiMAX MAC layer, the modified packets in the stream are received and the signaling is processed. According to the processing, the WiMAX MAC layer may reserve a 200 kilobit per second bandwidth through the data communication network  108  to the destination of the video stream. The WiMAX MAC layer may then arrange the transmission of the video stream through the data communication network  108  to the destination. 
         [0060]    In alternative scenario, the user of the computing device  100  may specify QoS Policy parameters. These parameters can be detailed and common QoS parameters such as bit rate, delay, jitter and packet loss which can be translated directly to QoS embedded in the underlying media type. However, not all media types support all or any QoS parameters configured. In that case, the network-aware adapter  430  may do the mapping based on media type. 
         [0061]    The foregoing provides a method for adapting a data stream such that a selected QoS Policy setting can be signaled to a MAC layer. However, it has not been considered, thus far, how to handle a scenario wherein the current network conditions will not allow the signaled QoS Policy settings. In such a case, the network-aware adapter  430  may schedule traffic in the stream associated with the QoS Policy settings according to best efforts. Alternatively, especially where the QoS Policy setting is associated with an all-or-nothing approach, the network-aware adapter  430  may reject the stream and inform the origin application and, in turn, the user. Further alternatively, especially where the QoS Policy setting is associated with a the QoS policy is associated with a “degradation is acceptable” approach, the network-aware adapter  430  may schedule traffic in the stream with degraded QoS settings. For some network media types, their QoS status (e.g., available bandwidth) can be monitored and fed back to the network-aware adapter  430  (through the QoS manager  432 ). 
         [0062]    Advantageously, the network-aware adapter  430 , when executing according to an aspect of the present invention, can be seen to mediate between the application layer and the MAC layer, thereby reducing a necessity for complexity in the applications executed at the application layer. The network-aware adapter  430  can be arranged to enable the specification of QoS parameters at the MAC layer. When used properly, the specified QoS parameters can be used to improve spectrum efficiency and facilitate management of complexities inherent in the data communication network  108 . 
         [0063]    Advantageously, an application can be developed in anticipation of interaction with the network-aware adapter  430  rather than interaction with the MAC layer that has been designed specifically for a particular networking technology. 
         [0064]    As should be clear to a person of ordinary skill in the art, although aspects of the present invention have been presented in the context of the known Windows Filtering Platform (WFP), the use of the WFP is not essential to the operation of aspects of the invention and merely serves as an example of an environment in which aspects of the present invention may be implemented. 
         [0065]    The above-described embodiments of the present application are intended to be examples only. Alterations, modifications and variations may be effected to the particular embodiments by those skilled in the art without departing from the scope of the application, which is defined by the claims appended hereto.

Technology Category: 5