Abstract:
Disclosed herein are methods and calculators for configuring traffic allocations for service classes with different Quality of Service (QoS) in a router. Example embodiments involve setting allocations at a router based on traffic rate values and/or traffic weight values provided by a user. The router may monitor actual traffic rates to ensure that traffic is not being dropped due to improper rate allocations and to provide historical data for optimizing traffic allocations. In addition, the router may automatically adjust traffic allocations to avoid dropping high(er) priority traffic. The router may also transmit alarms to the user and/or to other network devices to prompt traffic re-routing and/or re-allocation of traffic rates. Example methods and apparatus ensure appropriate traffic allocation to meet certain QoS metrics

Description:
RELATED APPLICATIONS 
       [0001]    This application is a continuation of U.S. application Ser. No. 13/216,513, filed Aug. 24, 2011, which claims the benefit of U.S. Provisional Application No. 61/378,065, filed on Aug. 30, 2010. The entire teachings of the above applications is incorporated herein by reference. 
     
    
     BACKGROUND OF THE INVENTION 
       [0002]    Quality of Service (QoS) is a measure of telecommunications service quality provided by a carrier to a subscriber. In asynchronous transfer mode (ATM) networks, QoS may be defined on an end-to-end basis, e.g., in terms of how frequently packets are delivered intact and on time. Example ATM performance parameters used to calculate QoS include cell error ratio, cell loss ratio, cell transfer delay, and cell delay variability. 
         [0003]    Carriers typically divide ATM network traffic into classes, each of which is guaranteed a minimum QoS. Subscribers usually pay for class allocations based on the type(s) of traffic they expect to send and receive via the network. For instance, subscribers who expect to send time-sensitive traffic, such as voice traffic, may choose to pay for a greater allocation of higher class service, i.e., service with a better guaranteed QoS. Unfortunately, it is often difficult to determine the traffic weight and traffic rate settings necessary for achieving the desired QoS. In the past, difficulties in determining the appropriate traffic weight and rate settings have led to lost revenue for service providers. 
       SUMMARY OF THE INVENTION 
       [0004]    Embodiments of the present invention include methods and corresponding apparatus for configuring traffic allocations for a router. One example includes determining a traffic weight value for each of a plurality of traffic rate values, each of which is associated with a respective class of service. The example further includes setting traffic allocations for each class of service on the router based on the traffic weight values. Alternatively, examples may include determining a plurality of traffic weight values, then determining a traffic rate value for each traffic weight value. The traffic weight values and/or traffic rate values are then used to set traffic allocations for each class of service on the router. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0005]    The foregoing will be apparent from the following more particular description of example embodiments of the invention, as illustrated in the accompanying drawings in which like reference characters refer to the same parts throughout the different views. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating embodiments of the present invention. 
           [0006]      FIG. 1  is a diagram that shows a user interface for a weighted fair queuing (WFQ) calculator that can be used to determine traffic weight values from traffic rate values (and vice versa) for configuring traffic allocations in a router. 
           [0007]      FIG. 2  is a diagram that shows trend analytics in pivot table (left) and pivot table graph (right) formats. 
           [0008]      FIGS. 3A and 3B  are flowcharts that illustrate example procedures configuring traffic allocations in a router. 
           [0009]      FIG. 4  is a diagram that shows a computer network or similar digital processing environment in which embodiments the present invention may be implemented. 
           [0010]      FIG. 5  is a diagram of the internal structure of a computer (e.g., client processor/device  50  or server computers  60 ) in the computer system of  FIG. 4 . 
           [0011]      FIG. 6  is a block diagram of a multi-service internet protocol network with a multi-service routing platform. 
           [0012]      FIGS. 7A and 7B  are block diagrams of example configuring devices, in accordance with embodiments of the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0013]    Currently, there is no defined or published documentation which explains how traffic weights are used or how to rate-limit broadcast/multicast traffic. This has led to some level of confusion and frustration for the end-users of network routers. In addition, it may be useful to leverage the abilities of most network routing platforms and enhance them to include mechanisms to generate additional revenue for end-users. 
         [0014]    Embodiments of the present invention simplify advanced Quality of Service (QoS) configurations on network routers, such as a Tellabs® 8800 Multi-Service Router or other suitable router or routing component. Example embodiments also clarify the role of weighted fair queuing (WFQ) values on QoS and the impact of WFQ values on traffic flows. Example embodiments assist in proper provisioning of QoS in the network routers and reduce or eliminate a possibility of lost revenue due to an inadequate or improper traffic allocation configuration. 
         [0015]      FIG. 1  shows a graphical user interface for a WFQ calculator that simplifies QoS and provides some general considerations for WFQ. The calculator, which may be implemented on a specialized or general-purpose processor, converts between the weights specified in each queue and the end result of bearer traffic that is actually being delivered (and vice versa). The calculator also teaches an average user how traffic rate values relate to traffic weight values. 
         [0016]    In the example shown in  FIG. 1 , the calculator operates on the following traffic rate values: 40% for constant bit rate (CBR) traffic; 30% for Class 2 variable bit rate (VBR) traffic; 20% for Class 1 VBR traffic; and 10% for best-effort (BE) traffic. CBR traffic receives 40% of the available 100 kbps interface bandwidth, or 40 kbps. The other traffic shares the remaining 60 kbps of interface bandwidth in proportion to the traffic rate values entered in the calculator. The calculator uses the traffic rate values to determine the traffic weight values for the VBR and BE traffic according to the following example formula: 
         [0000]    
       
         
           
             
               
                 W 
                 x 
               
               = 
               
                 
                   R 
                   x 
                 
                 
                   100 
                   - 
                   
                     R 
                     CBR 
                   
                 
               
             
             , 
           
         
       
     
         [0000]    where W x  and R x  are the traffic weight and rate values, respectively, for the class in question, and R CBR  is the CBR traffic rate value. In this case, the traffic weight values are 50 for Class 2 VBR traffic, 33 for Class 1 VBR traffic, and 17 for BE traffic. Those skilled in the art will appreciate that traffic rate values can be calculated from traffic weight values in a similar fashion. The calculator determines target allocations from the traffic rates by multiplying the remaining 60 kbps of interface bandwidth with the traffic weight values, then dividing by 100. Next, the router is configured using the allocations. 
         [0017]    Once the QoS configuration is complete, the router polices and shapes traffic to the specified criteria, e.g., the traffic allocations. Packets that exceed the limitations may be dropped or discarded. For some carriers, that functionality alone is sufficient. However, there is additional revenue that is being overlooked in this regard. For example, it may be useful to set-up thresholds on each queue so the carrier can apply analytics and generate reports that indicate what percentage of each queue is actually dropped. This notification can come in the form of an alarm notification that is generated by a management system. 
         [0018]    Consider a QoS configuration where 40% is allocated to real-time voice, 30% to mission-critical data, 20% to business services, and 10% to best-effort Internet services, as in the example of  FIG. 1 . If the carrier analyzes the data and finds that the customer is actually sending close to 50% mission-critical traffic, then 20% of the mission-critical traffic may be discarded. The carrier can then alert the customer to this detail, allowing the customer to purchase more bandwidth from the carrier and/or to readjust the bandwidth profile to better fit customer needs. The carrier can provide this service as a “Network Traffic-Utilization Monitoring Service,” thus opening a door to provide not only transport services but also Professional Engineering Services. Deep packet inspection (DPI) can also be developed on routers to view the layers 4-7 (of the ISO stack) of the IP data and provide more in-depth policy management so that customers can have a better understanding of the type of data that is transported on their network(s). 
         [0019]    The capabilities that can be added via DPI include network trend analysis and automatic weight adjustment. Network trend analysis is based on the understanding of the percentage of the traffic flow for each traffic class transiting the router based on DPI and rate/weight determination described above. Performing additional data collection enables service providers to better understand the traffic flow for each service type. For example, the router may collect data indicating traffic trends for each service class as a function of time (e.g., on hourly, daily, weekly, and/or monthly schedules). The router can also further inspect the traffic to understand what traffic type (e.g., Internet, business services, real-time voice) is being transmitted and/or received within each service class. In addition, the router can look even deeper into individual traffic type to get more detailed information, such as internet web-addresses, IP addresses, area codes, etc. These analytics can be raw CSV data that can be exported to a spreadsheet program and then automated into a pivot table and pivot table graph, such as the table and graph shown in  FIG. 2 . 
         [0020]    When traffic reaches a certain (e.g., pre-determined) threshold, the router can send an alarm to other devices on the network, such as a management system. The alarm may also be transmitted to the customer. The router can also automatically adjust traffic allocations to alleviate congestion. For example, in one embodiment, if the allocation for mission-critical data is set at 20% and the actual traffic rate for mission-critical data reaches 90% of its allocation (i.e., 18%) threshold for 30 minutes, the system automatically increases the allocation by 10% to a net percentage of 22% so that mission-critical data is not lost. The allocation for lower-priority traffic, such as BE traffic, is automatically scaled back to accommodate the increase in allocation for the higher-priority mission-critical traffic. When a system reaches a threshold, not only does it adjust its weight, it also sends control traffic to the upstream or downstream device so that the upstream of downstream device can make the same adjustment. In a point-to-multipoint network, it is also possible to designate which system makes the weight adjustments since the net aggregate of the multipoint devices need to equal 100% of the through-put of the single point device. 
         [0021]    In addition, it is useful to limit broadcast/multicast traffic from generating a layer 2 storm which can impact virtual private local area network service/virtual private wire service (VPLS/VPWS) architecture. Embodiments of the present invention can be used to generate and apply multicast rules on dropping broadcast/multicast traffic. For instance, the code reproduced below prevents generate of layer 2 storm on an example router, such as a Tellabs® 8800, in the absence of a multicast rate-limiting command. 
         [0000]    
       
         
               
             
               
             
               
               
             
               
               
             
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
               
               
             
           
               
                   
               
               
                 RATE-LIMITING BROADCAST TRAFFIC - the below example 
               
               
                 uses a traffic-param named BROADCAST_STORM_RX 
               
               
                 that is applied as the multicast rule in the qos-group. 
               
               
                   
               
             
             
               
                   
               
             
          
           
               
                 This enables this traffic-param to drop any broadcast/multicast traffic 
               
               
                 above 10% of the group rate of 10Mbps in this example. 
               
               
                 8830.28(cfg-br-inst[TestME])# show running-config qos traffic-param-list 
               
               
                 name G_Option_2_Rx_TPL 
               
               
                 # Running Config On: Wed Jun 9 21:04:02 2010 
               
               
                 # Software Version : 8.0.1.1.206 
               
               
                 exit all 
               
               
                 enable config qos 
               
             
          
           
               
                   
                 traffic-param-list name G_Option_2_Rx_TPL 
               
             
          
           
               
                   
                 rule 1 traffic-param G_Option_Best_Effort_2_Rx 
               
               
                   
                 rule 2 traffic-param G_Business_Option_2_Rx 
               
               
                   
                 rule 3 traffic-param G_Mission_Critical_Option_2_Rx 
               
               
                   
                 rule 4 traffic-param G_Real_Time_Option_2_Rx 
               
               
                   
                 rule 5 traffic-param BROADCAST STORM RX 
               
               
                   
                 exit 
               
             
          
           
               
                 8830.28(cfg-br-inst[TestME])# show running-config qos traffic-param 
               
               
                 name BROADCAST_STORM_RX 
               
               
                 # Running Config On: &lt; Time and Date&gt; 
               
               
                 # Software Version : A.B.C.D.E 
               
               
                 exit all 
               
               
                 enable config qos 
               
             
          
           
               
                   
                 traffic-param name BROADCAST_STORM_RX 
               
             
          
           
               
                   
                 service-class UBR-rrd 
               
               
                   
                 traffic-rate 
               
             
          
           
               
                   
                 fractional bandwidth 10 
               
               
                   
                 exit 
               
             
          
           
               
                   
                 weight 10 
               
               
                   
                 exit 
               
             
          
           
               
                 8830.28(config)# show running-config qos qos-group name 
               
               
                 Gold_Option_2_100Mbps 
               
               
                 # Running Config On: &lt;Time and Date&gt; 
               
               
                 # Software Version : A.B.C.D.E 
               
               
                 exit all 
               
               
                 enable config qos 
               
             
          
           
               
                   
                 qos-group name Gold_Option_2_100Mbps 
               
             
          
           
               
                   
                 rx-qos 
               
             
          
           
               
                   
                 traffic-param-list G_Option_2_Rx_TPL 
               
               
                   
                 multicast-rule 5 
               
               
                   
                 group rate 10000 
               
               
                   
                 exit 
               
             
          
           
               
                   
                 tx-qos 
               
             
          
           
               
                   
                 traffic-param-list Gold_Option_2_Tx_TPL 
               
               
                   
                 group rate 10000 
               
               
                   
                 weight-profile class0 14 class1 29 class2 57 
               
               
                   
                 profile class0 0 class1 100 class2 100 class3 100 
               
               
                   
                 exit 
               
             
          
           
               
                   
                 exit 
               
               
                   
                   
               
             
          
         
       
     
         [0022]      FIGS. 3A and 3B  are flowcharts that illustrate how procedures  300  and  350 , respectively, according to embodiments of the present invention configure, set, and apply traffic allocations for routing packets transiting a router in a network. In the procedure  300 , traffic rate values are received ( 302 ) for each class of service and used to determine corresponding traffic weight values ( 304 ), as shown in  FIG. 3A . Alternatively, the procedure  350  traffic weight values can be received ( 352 ) for each service class and used to determine corresponding traffic rate values ( 354 ), as shown in  FIG. 3B . Next, traffic allocations are set ( 306 ,  356 ) for each class in response to the determination of traffic weight/rate values. 
         [0023]    The router can optionally monitor traffic ( 308 ,  358 ), possibly by performing DPI ( 310 ,  360 ) and/or trend analysis ( 312 ,  362 ) as described above. If actual traffic rates deviate from allocations ( 320 ,  370 ), the router may drop packets from overflowing queues and/or automatically adjust the allocations to match the actual traffic rates ( 322 ,  372 ). In addition, the router may emit an alarm ( 324 ,  374 ) to the service provider and/or the customer. The router may also transmit the alarm ( 326 ,  376 ) to other devices connected to the network, e.g., in order to alter the composition of traffic flowing to or from the router. 
         [0024]      FIG. 4  illustrates a computer network or similar digital processing environment in which embodiments of the present invention, such as the WFQ calculator of  FIG. 1 , may be implemented. Client computer(s)/devices  50  and server computer(s)  60  provide processing, storage, and input/output devices executing application programs and the like. Client computer(s)/devices  50  can also be linked through communications network  70  to other computing devices, including other client devices/processes  50  and server computer(s)  60 . Communications network  70  can be part of a remote access network, a global network (e.g., the Internet), a worldwide collection of computers, Local area or Wide area networks, and gateways that currently use respective protocols (TCP/IP, Bluetooth, etc.) to communicate with one another. Other electronic device/computer network architectures are suitable. 
         [0025]      FIG. 5  is a diagram of the internal structure of a computer (e.g., client processor/device  50  or server computers  60 ) in the computer system of  FIG. 4 . Each computer  50 ,  60  contains a system bus  79 , where a bus is a set of hardware lines used for data transfer among the components of a computer or processing system. The bus  79  is essentially a shared conduit that connects different elements of a computer system (e.g., processor, disk storage, memory, input/output ports, network ports, etc.) that enables the transfer of information between the elements. Attached to system bus  79  is I/O device interface  82  for connecting various input and output devices (e.g., keyboard, mouse, displays, printers, speakers, etc.) to the computer  50 ,  60 . Network interface  86  allows the computer to connect to various other devices attached to a network (e.g., network  70  of  FIG. 4 ). Memory  90  provides volatile storage for computer software instructions  92  and data  94  used to implement an embodiment of the present invention (e.g., using the example code detailed above). Disk storage  95  provides non-volatile storage for computer software instructions  92  and data  94  used to implement an embodiment of the present invention. A central processor unit  84  is also attached to system bus  79  and provides for the execution of computer instructions. 
         [0026]    In one embodiment, the processor routines  92  and data  94  are a computer program product (generally referenced  92 ), including a computer readable medium (e.g., a removable storage medium such as one or more DVD-ROM&#39;s, CD-ROM&#39;s, diskettes, tapes, etc.) that provides at least a portion of the software instructions for the invention system. The computer program product  92  can be installed by any suitable software installation procedure, as is well known in the art. In another embodiment, at least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. In other embodiments, the invention programs are a computer program propagated signal product  107  embodied on a propagated signal on a propagation medium (e.g., a radio wave, an infrared wave, a laser wave, a sound wave, or an electrical wave propagated over a global network such as the Internet, or other network(s)). Such carrier medium or signals provide at least a portion of the software instructions for the present invention routines/program  92 . 
         [0027]    In alternative embodiments, the propagated signal is an analog carrier wave or digital signal carried on the propagated medium. For example, the propagated signal may be a digitized signal propagated over a global network (e.g., the Internet), a telecommunications network, or other network. In one embodiment, the propagated signal is a signal that is transmitted over the propagation medium over a period of time, such as the instructions for a software application sent in packets over a network over a period of milliseconds, seconds, minutes, or longer. In another embodiment, the computer readable medium of computer program product  92  is a propagation medium that the computer system  50  may receive and read, such as by receiving the propagation medium and identifying a propagated signal embodied in the propagation medium, as described above for computer program propagated signal product. 
         [0028]    Generally speaking, the term “carrier medium” or transient carrier encompasses the foregoing transient signals, propagated signals, propagated medium, storage medium and the like. Similarly, the term, “non-transitory” covers computer-readable media, such as optical or magnetic disks, on which computer software or code(s) can be physically embodied. 
         [0029]      FIG. 6  shows a router  600 , which may be a Tellabs 8800 Multi-Service Router or any other suitable router, that aggregates the traffic from existing access equipment, such as Frame Relay switches, ATM switches, DSL Access Multiplexers (DSLAMs), IP routers, and Digital Cross-connect Systems (DCSs), onto an internet protocol (IP) network. The router  600  supports various network interfaces that accept multi-protocol incoming traffic. Arriving packets are encapsulated into multiprotocol label switched (MPLS) packets with a simple label stack that expedites the forwarding process in the core. At the receiving end, the MPLS packets are decapsulated back to the designated protocol and forwarded to the appropriate outgoing interface. This process applies to most existing network protocols and thus provides a neat solution for multi-service IP networks. 
         [0030]    Multi-service routers provide many benefits to service providers, including, but not limited to: control plane reduction through a unified IP transport for multi-service networks and reduced network complexity; unlimited scalability thanks to a hierarchical label stack; complete QoS support, including the routing configuration processes described herein; simpler network management through pre-established Label Switching Paths (LSPs) service that make is easier to provision point-to-point connections for edge subscribers, manage the traffic in the core for load balancing, and perform a fast re-route under a link failure; and additional features, including Class 5 features, such as Caller ID and Call Waiting. 
         [0031]      FIG. 7A  shows an example configuring device (or calculator)  700  to configure traffic allocations for a router  705  (e.g., the router  600  of  FIG. 6 ). The configuring device  700  has a determination module  710  and traffic allocation module  715 . 
         [0032]    The determination module  710  is communicatively coupled to the traffic allocation module  715 . The traffic allocation module  715 , in turn, is communicatively coupled to the router  705 . 
         [0033]    According to one embodiment, the determination module  710  is configured to determine a traffic weight value for each of a plurality of traffic rate values. Each traffic rate value is associated with a respective class of service. The traffic allocation module  715  sets traffic allocations for each class of service on the router  705  based on the determined traffic weight values. 
         [0034]    According to another embodiment, the determination module  710  is configured to determine a traffic rate value for each of a plurality of traffic weight values. Each traffic weight value in such an embodiment is associated with a respective class of service. The traffic allocation module  715  sets traffic allocations for each class of service on the router  705  based on the determined traffic rate values. 
         [0035]    In other embodiments (not shown), to perform (some or all of) the procedures  300  and  350 , described in reference to  FIGS. 3A and 3B , the configuring device (or calculator)  700  includes one or more of the following modules (or sub-modules); a packet dropping module, monitoring module, adjusting module, alarm module, inspection module, analysis module, and presentation module. These modules (or sub-modules) are communicatively coupled to the router  705 , determination module  710 , traffic allocation module  715 , and/or to each other, accordingly. 
         [0036]      FIG. 7B  shows another example configuring device (or calculator)  750  to configure traffic allocations for a router  755  (e.g., the router  600  of  FIG. 6 ). The configuring device  750  has an interface  760  and configuration processing module  765 . The router  755  and interface  760  are communicatively coupled. The interface  760 , in turn, is communicatively coupled to the configuration processing module  765 . 
         [0037]    The configuration processing module  765  is configured to determine: i) a traffic weight value or ii) traffic rate value for each of a plurality of traffic rate values. Each traffic rate value is associated with a respective class of service. The configuration processing module  765  sets traffic allocations for each class of service on the router  755  based on the determined i) traffic weight values or ii) traffic rate values, through (or using) the interface  760 . 
         [0038]    In other embodiments (not shown), the configuration processing module  765  may be further configured to perform the procedures  300  and  350  described in reference to  FIGS. 3A and 3B . 
         [0039]    In reference to  FIG. 7A  (and to  FIG. 7B ), in one embodiment, the traffic allocations, which are determined based on traffic weight or traffic rate values, are set on the router  705  ( 755 ) by way of a message, signal, or other indication  716  ( 766 ). 
         [0040]    In another embodiment (not shown), traffic rate or traffic weight values are sent to the configuring device  700  ( 750 ) (e.g., from the WFQ calculator of  FIG. 1  or from a network management element) as a message, signal or other indication. Such a message, signal or indication may be received by the configuring device  700  ( 750 ) through an appropriate interface. In yet another embodiment (not shown), the traffic rate or traffic weight values are entered into the configuring device  700  ( 750 ) by a user who uses a graphical interface like the one shown in  FIG. 1 . 
         [0041]    The configuring devices  700  and  750  may be a physical node in a network like the computers  50 ,  60  in the network  70  of  FIG. 5  or other network devices, such as a switch, optical transport system, or the router  600  of  FIG. 6 . The devices  700  and  750  may be part of a physical network node as a component, module, blade or card of that node. 
         [0042]    Alternatively, the configuring devices  700  and  750  may be a general purpose computer having a processor, memory, communication interface, etc. (described above in greater detail in reference to  FIG. 5 ). The general purpose computer is transformed into the configuring devices  700  and  750  and their components, for example, by loading instructions into the processor that cause the computer to, for example, determine a traffic weight value (or traffic rate value) for each of a plurality of traffic rate values, in which each traffic rate value is associated with a respective class of service, and set traffic allocations for each class of service on a router based on the determined traffic weight values (or determined traffic rate values). 
         [0043]    While this invention has been particularly shown and described with references to example embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the scope of the invention encompassed by the appended claims.