KR20010020340A - Predictive bandwidth allocation method and apparatus - Google Patents

Abstract

Preferably, the bandwidth allocation of the communication systems is provided in a predictive manner. Packets are identified with a particular data stream, and the characteristics of that data stream are used to predict future bandwidth requirements. The predictions are used to terminate or change the channel by allocating wideband channels, such as the B channels of the ISDN, according to the expected needs. The system is self-learning and preferably able to modify the rule base to make distribution decisions based on actual usage statistics, for example.

Description

Predictive bandwidth allocation method and apparatus

In early telecommunications, there were very few service options available to users under services belonging to what is now known as POTS (Simple Old Telephone Service), and the number of incoming lines, private or "joint subscriber line" services, There was a limit to selecting PBXs for users. In contrast, modern users can choose from a variety of services, each of which has associated advantages, including ISDN (in addition to POTS) services, T1 services, cellular services and the like. , Disadvantages and costs. Broadband telecommunications as the use of telecommunications extends beyond voice calls to include tele facsimile, digital (or voice modulated digital) signals (such as those used in network or Internet communications), and the like. Services such as ISDN and T1, which offer the possibility for others, have become particularly important. Communication in the form of information, such as video information, digital file transfers, still pictures, streaming audio, etc., often requires short bandwidths.

Nevertheless, broadband services, such as ISDN, have not been able to replace the conventional less suitable telecommunications services, mainly due to cost (including installation fees as well as access fees and tariffs). Some of the costs associated with ISDN and other bandwidth choices arise from the fact that, in many such systems, broadband channels are allocated to each subscriber, so that each subscriber is intermittently relatively short. Despite the benefit and use of the large bandwidth over time (e.g., while a relatively large file is being transferred), it arises from the fact that it must pay for the entire bandwidth for a long time. Thus, systems have been proposed that are generally (and incompletely) similar to "public subscriber lines" in bandwidth allocated by multiple users, but to be used as needed at other times.

One proposed system is called Always On / Dynamic ISDN (AO / DI). In AO / DI systems, the “D” channel is continuously available (always on). The relatively narrow bandwidth D channel is helpful to the user as a "home" channel, where one or more B channels are used for a relatively large amount of transmission and are closed when not needed. With such a system, a plurality of users can share the cost, so that the cost of an individual user is reduced in various ways. A given user does not have to pay for the channel during times when the wide bandwidth channel is not in use or during times when the end user does not need the channel. Since ISDN circuits are shared, a reduced circuit is needed to supply a given group of users, thus reducing equipment usage and line charges.

Some protocols have been proposed in the context of AO / DI systems, and among them, a multi-link point-to-point protocol (MLPPP) that enables aggregation of multiple channels. And Bandwidth Allocation Control Protocol (BACP), which operates "on top" of MLPPP to provide vendor-independent specifications for initiating and managing channel switching. Commentary on the proposed AO / DI, MLPPP and BACP is, for example, Vendor's ISDN Association (VIA), a California non-profit corporation whose location is bishop lunch (launch) 2,2694 bishop drive, shoot 105 “Always On / Dynamic ISDN” RFC- available from San Ramon, CA94583 (Bishop Ranch 2, 2694 Bishop Drive, Suite 105, San Ramon, CA 94583). It is possible to obtain it in 1990 and RFC 2125 respectively or from http://ftp.via-isdn.org/ on the Internet, which is incorporated herein by reference. However, these three systems do not dictate a system for determining when to do such distribution or disintegrant, while providing the ability to switch or allocate bandwidth, and do not propose a valid and efficient determination system. .

One viable approach is a queue-depth system that allocates a wide bandwidth channel when the number of communication packets accumulated in the processing queue has reached a predetermined threshold. Such a system is, in essence, based on the consideration of past lakes. If the traffic already being reached in a given amount in a given time, a wider bandwidth channel is allocated. These systems function at some level, but do not necessarily lower costs and ease of use. Indeed, there is a queue-depth system that increases the cost charged if no bandwidth switching or allocation occurs. For example, if a threshold is reached just before the end of the file transfer, for example, even if the end user can hardly or never benefit from the additional bandwidth (because the file transfer ends before or immediately after that additional bandwidth is allocated), the queue Depth systems seek to allocate additional bandwidth (and typically end users avoid costs). Since such thresholds are predetermined and fixed, simply selecting different thresholds cannot solve these problems. For example, increasing the threshold may avoid unnecessary charges resulting from useless B channel allocation in the above example, but transmissions with other characteristics (e.g. bulk but short data transfers) will benefit from high threshold systems. Can not.

Thus, a queue-depth system requires that a threshold be set to accommodate a particular mix of traffic for a given end user, for efficient use. However, a typical end user has neither the skills nor the time to achieve an optimal or useful threshold. As such, a queue-depth system is not only able to achieve a cost saving goal in many cases, but also requires relatively high administrative costs for practical use. Moreover, queue-depth systems are inflexible and incapable of adapting to changes in the nature of the data traffic (eg, changes in traffic over an entire day or longer period of time). Adjusting the threshold of a queue-depth system requires considerable time by a manager of relatively high skill. In addition, a queue-depth system cannot initially allocate bandwidth in a given data stream (e.g., cannot distribute bandwidth immediately after a few packets, such as just the first one to four packets), and at least a sufficient number of It must wait until the packet reaches a predetermined queue threshold.

Thus, it is useful to provide a system that can realize bandwidth allocation to reduce the cost for broadband said communications without requiring additional time and technology to install and maintain such a system. It is also useful to provide a system that can accommodate traffic or usage patterns that change over time.

It is also more useful to provide a system that can initially determine bandwidth allocation in the data stream, such as only after the first few packets have been received.

Some systems that provide broadband access put additional burden on end users, such as allowing end users to invest in additional critical hardware or software. Thus, it is useful to provide a system that realizes an efficient supply and low cost of the communicable broadband without requiring significant installation of software or additional devices at the end user location (customer side) for the system to operate.

In addition, some systems impose significant burdens on the telecommunications companies to realize efficient bandwidth distribution. For example, to realize a system that makes some changes or "residents" of the protocol stack, the vendor requires that the protocol stack be authenticated, which increases the vendor's cost to realize such a system. Since the communication systems use the various vendors' equipment and software, the bandwidth allocation processing procedure, which relies on a constant level of dialogue with the vendor's equipment and software, is that a vendor has default routing or other such communications equipment and software. By providing different versions of the software (ie, vendor-dependent), the cost of selecting the appropriate version required, and the devices and software of multiple router vendors The development and implementation costs associated with the provision of different versions of a large number of bandwidth distribution systems operating in conjunction with this increase.

Thus, bandwidth allocation devices and processing that reduce and minimize the cost borne by the telecommunications company and the developer, such as a system that is at least partly not vendor dependent, reducing or minimizing the cost to the telecommunications companies and developers. It would be useful to provide an order.

The present invention prioritizes the allocation of bandwidth, such as the allocation of ISDN-bearer channels based on size or other characteristics of the data stream, taking into account the effect of allocation on packets or other communications and / or communication costs. Permit ranking.

1 is a block diagram of the communication system useful in conjunction with an AODI networking application.

FIG. 2 is a timing diagram illustrating an example of channel usage distributed by cue-depth. FIG.

3 is a block diagram illustrating the flow of useful information for bandwidth allocation in accordance with an embodiment of the invention.

4 is a block diagram illustrating the realization of a module of an embodiment of the invention.

5 is a block diagram similar to the block diagram of FIG. 4 except showing additional client-side components.

6A and 6B are flow diagrams and block diagrams each illustrating processes of using the components of FIG.

7A and 7B are flow diagrams and block diagrams each illustrating a process with respect to real-time components in accordance with an embodiment of the present invention.

8A and 8B are a flow diagram and block diagram illustrating a process with respect to realization components in accordance with an embodiment of the present invention.

9A and 9B are flow diagrams and block diagrams each illustrating a process in connection with a retrofit component in accordance with the present invention.

10 is a diagram illustrating display of network router information in connection with an embodiment of the present invention.

11 illustrates an indication of a router usable in connection with an embodiment of the present invention.

12 illustrates an indication of planning options available in connection with an embodiment of the present invention.

Figure 13 illustrates a representation of a plan editor usable in connection with an embodiment of the present invention.

14A and 14B are respective flow diagrams and block diagrams of embodiments of the present invention showing self-learning.

15 is a flow diagram of an example according to an embodiment of the present invention that includes increasing the bandwidth for classifying data streams.

16 is a flow diagram of an example in accordance with an embodiment of the present invention, including increasing the bandwidth when no data stream is identified.

17 is a flow diagram of an example in accordance with an embodiment of the present invention that includes increasing the bandwidth in response to a data lake.

18A is a schematic diagram of a counter used in a pegboard self learning system.

19 is a schematic diagram of a table tracking data streams of unknown type usable in accordance with an embodiment of the present invention.

20 is a schematic block diagram illustrating the disclosure in accordance with an embodiment of the present invention.

21 is a schematic block diagram illustrating packet rate control according to an embodiment of the present invention.

22 is a schematic block diagram illustrating security features in accordance with an embodiment of the present invention.

23 is a schematic block diagram illustrating media routing according to one embodiment of the present invention.

24 is a schematic block diagram illustrating processing outside the stream in accordance with embodiments of the present invention.

The present invention encompasses awareness of at least a portion of the problem of previous processing sequences, including the foregoing. The present invention utilizes queue-depth and other (or in addition to) features that allow bandwidth allocation to achieve more efficient bandwidth utilization on average, and increase the likelihood of users desirably lowering costs (on average on average). And making decisions that are based at least in part on the prediction configuration. In this and other methods disclosed, the present invention is used to manage and provide service levels for data and signal communication.

According to one embodiment, data packets are identified as belonging to particular data streams. The nature of the data stream (ie, the classification related to the type of data being transmitted, such as GIF data, streaming video data, text e-mail or batch binary downloads), provides additional bandwidth for use in future transmissions of packets in this data stream. The decision is made as to whether it is effective and / or cost-effective to allocate. For example, in one embodiment, reception of the first few packets of the GIF stream results in additional bandwidth allocation (eg, if the system predicts that a relatively large amount of GIF data will come during the rest of the data stream). Receiving the same amount of data classified as text E-mail (i.e., achieving the same queue-depth as the GIF stream described above) is such that if the system is relatively short or unrecognized, i.e. not immediately received, It will not allocate additional bandwidth.

In one embodiment, the system may access fields or various components of data packets to associate a particular stream with a packet (such as source / destination / port information or, in some cases, data field information). The system preferably uses various processes to classify specific data according to the data type. In some implementations, in addition to using a classification of data streams according to data type, other information is used that is useful for predicting future bandwidth requirements for the data stream (for a given user, what happens during a particular period of time). (Such as the knowledge that certain types of data streams tend to be relatively long or relatively short). The system is preferably a system based on heuristic teaching, and in one embodiment, such additional predictive information is developed and used by self-learning or by artificial intelligence systems. In this way, the system can change the overtime by itself in an automatic way. In this context, "automatic" means that the system can be configured so that human input supplements or ignores automatic analysis, even if the goal is required without analysis, determination, or other inputs from the operator or administrator (although it is required). ) Means achieved by a computer or computer system. It is believed that providing at least certain portions of the present invention with byte code systems makes it easier to change the rules (as shown later), ie to make self alteration or self learning easier.

It is preferred that the system be substantially assembled in modules. In one embodiment, the module directly monitored or connected to the communication line is configured to include only items that are performed in real time, and configured to operate quickly by performing as a byte code system, which is an efficient or suitable byte code system. desirable. Other components of the system, such as configured to analyze system behavior or provide learning or other artificial intelligence capabilities, may be used in cycle-steal mode (to use routing computer facilities while the routing computer is resting in reverse). Is configured to reduce or minimize the load on the computers routing.

In one embodiment, the system is preferably substantially independent of the seller by using the seller API. Seller-independence is encouraged by limiting code modularization and seller-dependent components, that is, to some well-defined functions.

Before describing the features of the present invention, it is believed that it is useful to describe specific features of an AODI networking application and an example of queue-depth control. In the following, references to the types of circuits or communication circuits include other "any layer" physical media, with reference to the OSI model. As will be apparent to those skilled in the art after understanding the present disclosure, some or all of the features of the present invention may be realized when the communication line or communication line is wireless. In the system shown in FIG. 1, the data server 12 (which may include one or more computers) and the client 114 are connected to one side of the router 116, and the router 116 is connected to the ISDN communication line 118. It is connected to the server side using. In a typical situation, router 116 is connected to a client that includes a broadband connection 133 over a local area network (LAN) 135. The ISDN circuit shown includes a D channel 122 and first and second B (bearer) channels 124, 126. D-channel 122 has a relatively narrow bandwidth, for example, to accommodate rates of data up to about 9.6 kilobytes per second. As mentioned above, in an AODI system, the B channels are circuit-switched (eg according to BACP and MLPPP protocols).

In one implementation of AO / DI, the D channel 122 is always on (always off-hook). In one implementation of AO / DI, calls are initially placed and handled on the D channel by using packetization procedures such as those known as X.25. Since the D channel is always on, it is possible to provide always available services, including, for example, "promotional mail". When it is determined that additional bandwidth should be provided, one or two bearer channels are switched to assist in data transmission. Typically, bearer channels use MLPPP (eg, without the X.25 packetization used on the D channel). When it is determined that such bandwidth should be discontinuous, one or two B channels must be disconnected.

The usefulness of AO / DI will relate to how bandwidth is allocated, that is, decisions are made that add or subtract B channels. It is possible to make decisions based on recent lakes of data traffic, such as making a decision based on whether the depth of data of the data in the router queue 128 reaches a predetermined threshold. 2 represents a (simple) example of queue-depth determination and also shows one of the disadvantages of such a system. In FIG. 2, the queue depth 212 is initially low but begins to increase relatively rapidly when data communication begins at time T ₁ . As noted above, communication is initially performed by D-channel 214. However, since the D channel is relatively narrow bandwidth, the cue-depth rises rapidly after T ₁ , reaching a predetermined queue depth threshold 216 at time T ₂ . Reaching threshold 216 at time T ₂ triggers the decision to switch-in B channel number 1. This decision takes a certain time, so in the illustration of FIG. 2, B channel number 1 is switched in at time T ₃ 218. The bandwidth of the B channel is relatively large and the queue depth quickly drops to a level 222 below the threshold 216. In the example of FIG. 2, the transmitted data has a relatively large bandwidth requirement, and after time T ₃ the queue-depth continues to rise even though it is slower than during the period after time T ₁ . In the example shown, the cue-depth once again reaches a threshold 216 at time T ₄ 224 which triggers a decision to add the second B channel. In the example shown, however, the data transfer is completed shortly after time T ₄ . Nevertheless, because of the delay involved in the switching on the B channel, and then because of the delay involved in the B channel switching out or discontinuity, in the example shown the B channel number 2 is switched at time T ₅ , and time T ₆ Until it is switched out. Thus, in the example of FIG. 2, even though the user has no benefit from the use of the B channel number 2 (because the data transmission is completed before the B channel switch-in), the user has time T _5. You will be charged for the use of the B channel number (2) between and T ₆ .

3 illustrates a system in block form, in accordance with the present invention, capable of making bandwidth distribution decisions based on queue depth and other (or additionally) information. Details of the system will be described below. In general, information related to the characteristics of the data, as shown in FIG. 3, is passed 312 to the decision system 314. The decision system may use the MLPPP 318 and BACP 322 to realize such switching in a manner that should or should not be bandwidth allocated and to avoid data flow confusion while these decisions achieve the desired bandwidth allocation. Determine if and when to execute (316). In the detailed embodiments below, the determination system 314 uses a rule base to make decisions and provides a development environment for building rule bases. In one embodiment, decision system 314 may provide self-learning capabilities (artificial intelligence) to modify its own rule base to meet changing environmental needs. The rulebase architecture is preferably independent of the vendor and provides a management tool that can be cross-recognized to the hardware systems of the various vendors, i.e. administrators can manage systems that have been changed from a single console at the same time. It is preferable to include.

In one embodiment, heuristic analysis is used to realize a self learning system. One example of a heuristic analysis is called a "pebboard" system. In an example of a heuristic method of the board type, the system provides when (a) to perform an evaluation of the performance of the system, how the performance is evaluated (b) and how to improve the rules when performance is not good enough. . In one panel system, separate counts of messages (such as the total number of messages of a particular type) or the total number of such data streams that are handled correctly are accumulated in a software counter (or hardware in some cases). The particular type of total data stream and the total number of counters handled correctly can be visualized in the first and second panels 1812 and 1814 as shown in FIG. 18A and FIG. 18A is darkened in the first panel 1812. The painted circles represent the number of specific types of data streams (in the city, the number of e-mail sessions) in a particular period (eg, since the last assessment of performance), and the dark colored circles in the second panel 1814 Shows the number of e-mail sessions handled correctly. For purposes of illustration, a widely practiced rule base is constructed based on the assumption that E-mail sessions are relatively small and thus provide rules that do not increase bandwidth for E-mail sessions. Thus, in the illustration in FIG. 18A, each time a new E-mail data stream is handled, its counter or panel 1812 is incremented. Steering of the e-mail session is evaluated to determine if the e-mail session is steered correctly, and if the correct steering is determined, the second counter or peckboard 1814 is incremented. Evaluation processes can consist of many ways to determine if the steering of an e-mail session is correct. For example, the rule, which does not specify increasing bandwidth for an e-mail session, is based on the assumption that the e-mail session is small, so in fact, if a particular e-mail session is small (less than the threshold), It is possible, however, to construct a software evaluation such that the manipulation of a particular e-mail session under the current rule base is considered "accurate". Evaluation of other types of performance is also possible. For example, the actual manipulation of the e-mail may be possible to configure the software to be compared to one or more possible alternatives to maneuvering the e-mail (such as increasing bandwidth) and to determine if the actual manipulation can be improved. (Eg, to provide better performance at a relatively low cost, or to be closer to the performance criteria set by the user).

In other cases, it can be seen from the foregoing that the software is configured to automatically include a count at the panels 1812, 1814. As will be apparent to those skilled in the art, it is also possible to provide a setting of the panes or counters for other types of messages (eg, in addition to the illustrated E-mail panel).

In order to perform function (b), the information accumulated effectively on the clipboards at some point is considered to be sufficient for evaluation. Many systems are used to determine when evaluations will occur. In the illustration of FIG. 18A, the evaluation is performed when one of the counters or the panels 1812, 1814 reaches a maximum value, that is, one of the panels 1812, 1814 is “sufficient” ( 1816), any time. Other criteria for initiating the assessment can also be used with the passage of a predetermined time period, such that a threshold is reached at the first panel (not at the second) and a threshold at the second panel (but not at the first). And an initialized user need to assess the performance of the system as a whole and the cost and performance of the system as a whole, and reach various thresholds and the like (such as thresholds that vary from hour to day).

In the illustrated embodiment, since the "right" steering of each individual e-mail session was individual and desired to be evaluated continuously, once the evaluation cycle is reached, the system evaluation performance is simply performed by correctly controlled sessions 1814. Can be found by comparing the number of to the total number of sessions 1812 in a given timeframe. For example, if the configuration of the software is correct so that the ratio of the totally controlled e-mail sessions and the total number of e-mail shunts in the time frame is less than the predetermined rate, then the system may rule in an attempt to improve performance. You will start to change the base.

In the example shown, the bandwidth for e-mail sessions in response to detection of poor performance (a relatively low ratio of precisely steered e-mail sessions to total e-mail sessions) to make the current rule base unacceptable. Since it does not include increasing the system, the system will change the rules base, such as allowing an increase in bandwidth in response to E-mail traffic, such as a certain minimum of E-mail traffic. As will be apparent to those skilled in the art, other ways to modify the rule base to detect poor performance are provided by initiating queuing of E-mail messages or the like.

FIG. 18A shows a boardboard-type heuristic method, other forms of self-learning, and heuristic self-learning methods can be used. For example, a more general heuristic method involves obtaining information on a plurality of different characteristics of data streams (date, time, efficient data rate, port number, and manipulation under the current rule base), and a plurality of different characteristics. Can be analyzed to determine over many data streams, and the causes are most relevant to the performance of the system. As an example, the system is configured to obtain and store information related to messages of unknown type and their data streams. As mentioned above, this system typically uses some rules in the current rule base to manipulate unknown types of data streams, resulting in the decision not to switch to a higher bandwidth or switch to a higher bandwidth for these data streams. Will have processes. In an example of a more general heuristic, the system maintains a track of port numbers for such unknown types of data streams, for example, and reports the frequency of unknown data types associated with each port and switching (e.g. , In a table 1912 as shown in FIG. 19). According to this example, analysis is performed periodically to evaluate the manipulation of unknown data streams under the current rule base. For example, the information shown in FIG. 19 can be used to select session types or those sessions that seem to have the greatest impact on the system. In this city, the category of unknown data streams with the biggest impact (such as unknown data streams with the most frequently occurring specific port address) are then analyzed to determine if they have been "correctly" manipulated. . Analysis of the "correct" steering can be performed by many methods, including those mentioned above in connection with the example of FIG. 18. For example, it is determined whether different switching decisions resulted in unacceptable performance other than the low price (eg, if the system is configured or the users instructed to keep the price at a consistent minimum level with the desired level of performance). In one example, if relatively many unknown types of data streams are not steered correctly, the decision is made automatically about how to change the rule base in an attempt to improve performance.

In one embodiment, this decision on how to change the rule base is based on the following analysis, which correlates correct and inaccurate switching decisions with many different possible correlations (eg, some likelihood). Correlates to what is determined as candidates). Examples include correlating accurate and inaccurate switching decisions with the effective data rate and the like over a certain transmission period and the date and time the packet is sent and the “abrupt / continuous” behavior of the packets.

Based on this analysis, one or more correlations are identified as having a relatively significant correlation with the accuracy of the steering and that correlation is used as the basis for changing the rule base. For example, if it is determined that the majority of incorrectly steered unknown types of data streams occur between noon and 3 pm and / or during a particular port number, the rule base may be used for unknown data streams generated during those times. It is changed to make different switching decisions. The system will temporarily add new rules for this unknown data type and use this new rule set to replace the previous rule set for the unknown session type. The counters (such as those shown in FIG. 19) are at least subsequently reset for categories related to the changed rules, and the system continues to accumulate and perform information for performance analysis based on later heuristics. .

In addition to using the identification of the data stream type for the purpose of bandwidth switching, the data type can be used for other purposes. In one embodiment, data stream types are identified and used for queuing of data streams (such as weighted smooth queuing). Such queuing may be used in addition to or in place of the bandwidth selection or switching described above. 20, the system 2012 is located in a router 2014 that receives the incoming 10 Mbps LAN packet stream 2016 and outputs a 128 Kbps WAN packet stream 2018 in the illustrated embodiment. It is located in the data stream together. In the illustrated embodiment, voice and video data packets are provided at the highest priority 2022, while E-mail and Internet "web" packets are provided at the lower priorities 2024, 2026. If the bandwidth of the output stream 2018 is not fully utilized, the packets of the packet stream 2016 are positioned substantially in the output line 2018 without buffering. However, if the bandwidth of the output stream 2018 is not fully utilized, the system queues the packets when they arrive, for example by placing the packets in the other queues 2028a, b, c. Other cues are provided at different priorities, such as providing a cue 2028a corresponding to the voice and video having the highest priority 2022. Router 2014 outputs packets from queues 2028a, b, and c, but need not output packets in a way that goes in the order in which they arrived, and does not need to provide the same distribution from the various queues. Instead, the packets in the highest priority queue 2028a have an output with a higher frequency (mixing the input frequency or the same or proportional frequency) than the packets in the lower priority queues 2028b, c. to be. Thus, while incoming packet stream 2016, voice and video represent approximately one third of the packets, the voice and video packets are more frequently output so that in the output stream 2018 shown in the example of FIG. This represents 50% of these output packets.

21 introduces another method that system 2112 can use to increase performance and reduce cost in a data stream. In the example shown in FIG. 21, a video receiver transmits requests for video packet data of a specific size to a video transmitter (eg, through a WAN packet stream 2118 of 128 Kbps) via a LAN packet stream 2116 of 10 Mbps. Related to. In this example, system 2112 is used for packet rate control. For example, a video receiver may be requesting a certain amount of video data, but it will not be the most efficient to send all the packets needed to complete the data request at once. After determining the effective data rates for incoming and outgoing packet streams 2116, 2118, according to the example of FIG. 12, the system may determine a " virtual " data rate for video such as the data rate previously requested by the administrator. Consider. For example, an administrator can request video data at a rate of 64 Kbps or 8 Kbps, for example. The system 2112 calculates the maximum "chunk" size of the data to maintain speed control. For video (for packet rate control over a line such as 2118, which is 128 Kbps), this may be set, for example, to 4 KB chunks requested twice per second. This chunk size can be adjusted as needed to prevent timeouts. In this situation, when a video packet data request "ACK" is received, the swap system 2112 changes the size of the amount of data requested. For example, the system selects the size of the minimum value that falls between the calculated maximum chunk size and the requested data. As an example, if the video receiver sends a request for 32 KB, the system 2112 instead outputs a request for 4 KB to the transmitter. When the system 2112 realizes that the requested 4KB is sent from the transmitter 2126, leaving the remaining amount of 28KB 2128, the system 2112 then outputs another request for 4KB. This process is repeated until the next requested 32 KB is provided to the receiver. In this way, in response to receiving a particular request 2122, the system 2112 converts it into a series of different requests 2124, 2132, and the like, which may result in the overall required performance and economic performance of the data transfer. To provide control of the packet rate in some way.

FIG. 22 provides an illustration of another method in which data stream type information is used to provide security functions such as, for example, a "firewall." In the illustration of FIG. 22, the system 2112 is located in a data stream (such as router 2214). 22 shows that the desired security characteristics are to reject all file transfer protocol (FTP) packets 2216 from within the satellite bank unless the time is between 4 pm and 8 pm and no security software key is sent to the router. Include.

In the illustration of FIG. 22, FTP packets 2216 on a 10 Mbps LAN packet stream are not provided on a 128 Kbps WAN packet stream. The reason is that in the city, the time is not between 4 pm and 8 pm or the security key is not sent to the router. In one embodiment, if HQ systems first "unlock" a secure connection to a router that allows, for example, up to a 15-minute transmission window, the system may, for example, allow access to satellite bank systems by HQ systems. Can be configured.

FIG. 23 shows an example of the use of system 2312 at router 2314 for routing different types of data streams on different communication media. For example, in the illustrated embodiment, packets on a LAN packet stream 2316 are either a low speed, low cost dial-up WAN 2318, a medium speed, medium cost ISDN WAN 2232, or a high speed, high cost fiber optic WAN. Routed to 2324.

Other forms of possible media may be present in the art. In the illustrated embodiment, the LAN packet stream may include many different types of packets including voice and video packets 2326, which in this example are considered timing critical data and require maximum performance. And, in this example, Web packets 2322, which are considered to be of average importance, and a method for minimizing costs, and E-mail packets 2328, which in this example are not considered time critical. The system 2312 operates to route packets to various media 2318, 2232, 2324 depending on the packet type through the buffers 2334a, b, c associated with each media. In the example of FIG. 23, the rule base for system 2312 is transmitted over an available high speed line or WAN 2324 when, for example, 2326, a private or mission sensitive packet is received in timing. . Less time-critical packets, such as for interactive applications, when packets and web packets 2332 are received, are sent over a less expensive medium speed line or WAN 2322, and e-mail. When packets and other less time critical packets are received, they are transmitted over the cheapest cost line or WAN 2318.

Although cities of system use have been provided including cities including switching, it is possible to provide applications outside of the system of many switching. Many such applications include inserting the packets 2418 generated into the packet stream and / or supplying copies of the packets in the data stream 2416 to the system 2412, as shown in FIG. 24. Examples of applications outside the switching system include monitoring the circuit, e.g. beyond usage, tracking traffic types, reporting to administrators, tracking usage characteristics of users connecting remotely, and efficiency of current connections. Compare cost and cost to theoretical connection types (eg, a certain profile of theoretical connection types), act as an increased intelligence firewall (to analyze security and recommend improvements), simulate data for diagnostic purposes, and play back To improve the transmission efficiency of data transmitted through the system, to study unexpected methods to improve the efficiency, to communicate with other systems to automatically provide redundancy, or to prevent and identify viruses To track byte patterns in packets, tunneled protocols It includes acting on things similar to security protocols and to identify them.

Determination system 314 includes many components, and in one embodiment, they are distributed. Others are present on the workstations of the system developer and / or administrator, while some components are on the vendor's device.

The system preferably operates on a stream rather than on a packet level. As those skilled in the art know. X.25, multi-line protocols and similar systems send certain data streams by sending a plurality of data packets, each of which comprises a portion of the data stream. Rather than making separate decisions for each data packet, the system identifies data streams that make and enrich decisions based on information about different data streams, respectively. Decision system 314 may determine all of the end time, start time, and size of the data stream, for example, via an ISDN interface. The system obtains information from the first few packets of the datastream and in some cases from only one (as first) packet of the stream (with enough information or other information identifying the data type of the stream). You can make this decision after obtaining.

In addition, the decision system 314 can identify other characteristics of the stream. In an Internet Service Provider (ISP) environment, for example, the decision system 314 can determine whether a particular stream sends FTP sessions and HTTP requests or some other type of transmission to the server. This information about the stream type can be used to make decisions about the predicted demand on underlying ISDN circuits, for example to serve as a basis for making decisions about when to add and terminate a channel. Table 1 provides a list of data stream types and specific characteristics of the data streams selected for illustrative purposes, which are useful for predicting future bandwidth demands for that data stream in a given environment. Other data types and characteristics are well known in the art including, for example, HTTP, SMTP, SNMP and H.323.

Data stream type Representative Characteristics FTP Large size, large standard deflection in size, usually time is not important HTTP Requests are small on average, responses are big on average, large standard bias in size, and relatively time critical SMTP (E-mail) Small size on average, time doesn't matter Video Conferencing / Audio Streams On average big size, time matters

In one embodiment, predictions for future bandwidth demand for the data stream are realized by a rule base. The rule base may preferably be changed automatically or manually based on traffic statistics. The decision system 314 preferably automatically gathers statistics useful for changing the rule base. Although it is possible to realize the decision system 314 in many ways in accordance with the present invention, the realization by rule base construction is not possible for system developers to handle different data streams in a relatively intuitive way through a series of yes / no decisions. It has been believed that it has been easier to program the decision system 314. Such system design or programming may be used with any of a variety of hardware configurations regardless of the underlying hardware. In one embodiment, reprogramming or changing of rules may be made without interfering with the operation of the system, eg, without having to reboot router 116.

Helping to achieve efficient execution of decision system 314 at the minimum portions of decision system 314 is preferably implemented as byte code. The rule base system is preferably compiled into vendor-independent byte code before being downloaded to the merchant device. The byte code is preferably developed to operate on the packet and to make binary (yes / no) decisions. Additional efficiency is preferably implemented by automatically instructing binary decisions for optimal or increased efficiency. In one implementation, some or all binary decisions result in setting flags for the session as they are made, so that the decisions made once need not be repeated unless needed.

Bytecode can be provided without the need to compile (as the interpreter provides the bytecode rather than the compiler). This approach can be useful for providing new or modified byte codes, which can be loaded into real-time components or components of systems without the need to interrupt or reboot the system.

Realization efficiency is further facilitated by the componentized or modular structure of the crystal system 314 as in the embodiment shown in FIG. In the embodiment of FIG. 4, real-time component RTC 412 associates with ISDN 119 data streams to obtain information about the packets as they pass through router 116. RTC 412 does not reside on such a stack, and instead it is desirable to obtain information about packets via vendor application program interfaces (API's). Since the protocol stack itself cannot be changed, the present invention is provided to vendors providing the necessary API's, and when realized, there is no need to prove the protocol stack again.

RTC 412 preferably includes most of the real-time operations of decision system 314. In the illustrated embodiment, the RTC 412 performs many functions. It can identify the start, middle and end packets of specific data streams. The RTC 412 uses rules provided by the byte code system or engine to determine when to open and close channels, ie switch channels. RTC 412 also aggregates statistics for data traffic. The types of statistics that are collected are preferably determined by the byte code engine.

In the embodiment of FIG. 4, the byte code engine executed by the RTC is provided to the RTC 414 by an adaptation component (AC) 416. This structure allows changing or updating the byte code engine executed by the RTC. In particular, AC 416 receives channel switches / opens / ends / decisions by RTC 422 as well as statistics on data stream characteristics. By fertilizing the received statistics against the existing rule base where the RTC is currently being used, the AC 416 can determine whether the rule base is more suitable for the current environment. AC 416 automatically generates a revised or changed version of the byte code engine (without human intervention) and downloads the enhanced or adapted engine 414 to RTC 412. In this way, AC 416 alters or adapts the RTC to meet the specific needs of environmental change. The statistics used by the AC are also preferably sent to the administrator console (console) 424 (in the embodiment described, via the realization component (IC) 428).

AC 416 does not need to operate in real time (or the choice of other methods, such as stopping or decelerating AC 416, will not immediately affect the current data flow). Non-real-time components, such as AC 416, are configured to operate only when router processor cycles are available (i.e., to use the router processor while the router processor is idle), so that AC 416 does not need to operate in real time. Modularization or differentiation of such components, such as), provides an opportunity to avoid imposing excessive computational loads on the router computer. The use of cycle-stealing is relatively complex and allows time-consuming analysis to be realized without affecting overall performance and without requiring significant additions or updating of routing processors or other hardware. As shown here, period-stealing and other efficiency gain measures make it possible to use the learning or artificial intelligence approaches described herein previously considered not viable for the communications routers because of the computational load involved. . The AC 416 also sends switch / open / end channel decisions 425 (made by RTC) to the IC 428. The main function of IC 428 is to implement decisions by RTC by interfacing with the vendors' completions of BACP 322 and MLPPP 318. IC 428 preferably calls BACP using Vendor API's to switch, open, and tear down channels as determined by RTC and transmitted over AC 416. IC 428 also stores statistical information 424 and sends it on 432 to administrator console 426. As shown in FIG. 10, the administrator console 426 is configured to display information about all routers, such as state 1012, which is the total active and inactive routers 1014 and similar in the network. desirable. As shown in FIG. 11, the administrator console 426 is capable of many forms of statistics for various routers, such as state 1112 such as bytes and packets, at various time periods 1114a, 114b, and the like. It is preferred to be configured to display detailed on-demand drawings.

New or changed rule bases may be developed by administrators using the illustrated management applications 426, 434. Such new rule bases are downloaded 436 to the AC 416 by the IC 428 (ie, Internet Protocol (IP) sockets), and the AC 416 is a byte code (good) that the RTC 412 can use. Is optimized). Conversion to bytecode, in particular efficient or optimized bytecode, can be a challenging task. In one embodiment, the task is achieved or assisted using processes based on the main implicator theory.

The administrator console 426 provides a graphical user interface (GUI) for the administrator to change or set parameters for rule bases operating on routers in the network (or specific portions of rule bases such as router plans and user plans). To supply. For example, as shown in FIG. 12, in one embodiment the administrator console 426 sets the maximum bandwidth for special users 1212, sets a plan for specific data types 1214, and plans. It may be configured to facilitate the selection of a particular plan by displaying drop-down boxes or other selection items to name 1216 and set something similar. The administrator console 426 also provides an easily accessible and understandable view of the statistics 432. In the illustrated embodiment, plan configuration component 434 is used by a network engineer to create and modify rule bases. As shown in FIG. 13, such planning is preferably facilitated by arranging "tree" drawings of the type familiar to many programmers or network engineers.

The administrator console allows simultaneous management of one or more decision systems 314 and a plurality of rule bases. The use of an interface, such as a socket-level IP interface to all decision systems, helps to realize this challenge. In such a configuration, the interface used in the administrator console, as well as the language used to change and create rulebases, is vendor-independent and will therefore appear identical to the administrator regardless of the type of merchant hardware present on a given IP network. .

As shown in FIG. 4, it is possible to implement the invention without changing the hardware or software of the end user or client 114. However, in some advantageous cases it is possible to provide a system that includes specific client side applications as shown in FIG. 5. In one practical example, the client connection component 514 helps establish a user's ISDN connection to both the telephone company and the Internet Service Provider (ISP). The management component 516 may be provided to provide the end user with a grade of control for his or her ISDN use (eg, through the use and modification of a user plan). This allows users to reduce the cost of data communication based on their special knowledge of their own request, and further increase the efficiency. The user, for example, wants to indicate a particular equilibrium between the costs and levels of service, for example, to specify that e-mail messages receive the highest priority regardless of cost. The server also wants to have several possibilities that affect the behavior of the system. In one embodiment, when the ISP wants to add or change the options available to the end user, the service provider can immediately send the changed conditions to the client side immediately.

6A and 6B illustrate the components and processing steps involved in making a channel switching decision in accordance with one embodiment of the present invention. In the configuration shown, when a data packet arrives at routers 612, 614, a copy of the packet 616 is delivered to the switching system 618, in particular by the router 624, to the RTC 622. The RTC uses the rule base 626 to decrypt the packet and determine whether or not to change the bandwidth 628. If the RTC does not change the bandwidth, the RTC will record its decision and send a recommendation 634 through the AC 638 to the IC 636. The IC 636 opens or closes the bandwidth switches 644a, b, c using a bandwidth control method to request adjustment to the bandwidth by the router 642. Regardless of whether a particular packet causes a change in bandwidth, the RTC 622 will report on a decision made to AC 646 from time to time or periodically. The AC 638 will evaluate these decisions and use its own larger rule setting to change the rules base 626 of the RTC 648.

7A and 7B illustrate the operation of the RTC in more detail. The packet processor 712 places the newly arrived packet copy into a packet queue, such as the first incoming (FIFO) queue 714, which can be processed by the rule base engine 716. The rule base engine 718 resets another "per packet" temporary variable 722 when it receives a packet from the queue 714 and starts processing 724 through the rule base 626. The rule base 626 decrypts a packet that depends on the operation code and / or analyzer 726, records statistics related to the packet and its state, and determines 728 whether a change in bandwidth occurs. If the execution of the rule base results in a change in bandwidth, the RTC 622 records its decision and sends a recommendation 734 (via AC) to the IC 636. As mentioned above, IC 636 uses a bandwidth control method to request adjustments 736 to bandwidth by routers 612. As noted, RTC 622 writes its decisions 738 and statistics periodically or occasionally to AC 742. Before processing the next packet, the RTC will determine if there is a new or changed rules base received from AC 638. If so, the RTC will wait until the processing of the current packet is complete (using the old rules base) (ie, will not process new packets from queue 714), and will refresh the old rules base. It will replace the rules base 746 and continue processing 748.

8A and 8B illustrate the processing and components of IC 636 in accordance with an embodiment of the present invention. In the illustrated embodiment, general manager 812 may receive status information from management applications 426 and 512 as plans are stored via data manager 814 (eg, on mass storage device 816). Request information from a data manager to satisfy recent data. The mass storage device 816 is used to store rule bases and data dictionaries, user restrictions, statistics and the like. The general manager 812 knows the internal command controller 822 for events 824 such as new plans. The command controller 822 also receives new statistics and status updates from AC 826 and the controller stores to data manager 828. The command controller 822 also instructs to change the bandwidth for receiving commands from the RTC 832 and sending them to the connection manager 836, 838 on 834. The connection manager 836 coordinates the switching-up and switching-down requests by communicating with the router's (612) connection manager (e.g., BACP or the like) to handle the progress of the connection requests 844. do.

9A and 9B illustrate components and operation of AC in accordance with an embodiment of the invention. The IC 636 is responsible for setting up the plans 912 such that the platform-intermediate format 914 (in the form of a new rule base, data dictionary, or other forms) is enabled by other realizations of the system 618. (Which can be read). The loader 916 converts the policies into a platform-specific format. For example, numbers are converted to 16-bit approved on Intel format, and operation codes are stored in a more compressed format and similar 918. The loader sends the plans to ACBM 924 (922). The ACBM 924, provided with a data dictionary 926a, an analyzer 926b, an operation code list 926c, and the like, derives a rules base from the policies and converts it to the main implementor 932 of the analyzer 934. To send). The main implement 932 reduces, rearranges, and compresses the rules base so that it becomes more efficient (936). The main implementor 932 then sends the rules base 938 to the RTC 942. Instead of or based on the rule base on the information received from the IC, it additionally generates it from the RTC to the main implement 946 and sends it to the main implement 946.

14A and 14B illustrate a method for facilitating self-change or self-learning according to an embodiment of the present invention. In the embodiment described, the IC downloads a 1412 data dictionary or rule base to the AC 1414. If the AC receives a data dictionary, it first extracts the rule base via the ACBM before downloading to the RTCs 622 and 1416. The RTC 622 processes and switches according to its rule base 626. Periodically or occasionally, the RTC sends statistics 944 and / or information (fingerprints) to AC 638, 1418 for unknown packets it finds. The AC 638 uses a rule base to delete, modify or add algorithms or rules 1422 made from its data dictionary 926a. Changes made to the data dictionary or rule base are passed to the IC for storage 1424. The AC 638 extracts a new non-optimized version of the rule base and sends it to the main implementor 932. The primary implementor 932 uses the rules of implicit reduction to optimize the new rulebase before sending the approved rulebase to the RTC 1428.

Figure 15 gives a relatively simple example of how a known packet causes a switch up (ie, adding a channel). As an example in Figure 15, the rule base 626 receives a packet and identifies the type of packet as HTTP (hypertext transfer protocol). The 1512 rule base verifies that this packet is a header for a new connection. The rulebase then checks if the packet specifies a session length of 670 kilobytes. The rulebase verifies that the length of this session is greater than the maximum number of bytes needed for the switch up. The session (data stream) is logged (information is stored and associated with the data stream identifier) to track the data stream, i.e., the progress of the session. The RTC creates a record to inform AC about statistics about this data stream and / or packet (eg by storing data or setting a flag), and whether it is switched up correctly (desired data transfer effect). It also helps the AC decide whether or not to modify the rule base or not. The RTC then sends a message to the IC via AC to cause switch up (adding bandwidth) 1526.

Figure 16 shows a simple example of a state where a switch up is performed as a result of receiving an unknown type of packet. As an example in Figure 16, a packet is received that cannot identify the type of data (1612). The rulebase obtains information (fingerprints) about this packet, such as the data length associated with the data stream, the number of packets in the stream, etc., and creates a record to pass the fingerprint information to the AC as before (1614). ). In the illustrated embodiment, there are two conditions 1616 and 1618 that cause a switch up request. The rule base may be configured to request a switch up when either of these conditions 1616 and 1618 is realized or may require that both conditions 1616 and 1618 be implemented before requesting a switch up. have. In the illustrated embodiment, the first condition is that the new data transfer rate including the new packet is greater than the maximum data transfer rate with respect to the current bandwidth setting (1616). The second condition is that the data transfer rate is too high (over the threshold) over a time period longer than the predetermined time for the current bandwidth setting (1618). By the construction of the rule base, when either or both of these conditions are realized, the rule base sends a message (via AC) to the IC to switch up (1622).

Figure 17 shows an example in which the switch up is performed when the streams are collected. In the embodiment of Figure 17, the rule base initially identifies the packet (1712) indicating the initiation of an E-mail session. As before, the rulebase cuts and tracks this session, i.e., the data stream, to create a record to inform the AC of the statistics (1714). The rule base determines (1716) that a switch-up should not be requested just because of the type of data, ie just because it is an e-mail session. In some configurations, it is considered that time is not an important factor in regards to an e-mail session, so that a rule base can usually be constructed so that no switch-up is performed. In the illustrated embodiment, the new data transfer rate including the new packet is greater than the maximum for the current bandwidth setting (1718) and / or at a time when the data transfer rate is longer than the predetermined time with respect to this current bandwidth setting. 1722 is determined to be too high. As a result, even if the packet has been identified as an E-mail packet, the rule base sends a message (via AC) to the IC (1724) to switch up. Bandwidth aggregation can be used in relation to both the aggregation of the attribute bandwidth and the aggregation of the actual bandwidth.

In view of the above description, many advantages of the present invention can be seen. It is desirable for the book system to make more efficient use of the available bandwidth, so that a plurality of users can share a B channel or other wideband media. In one embodiment, the present invention can provide a user to B channel ratio of greater than about 3: 1, preferably about 5: 1, more preferably about 8: 1, and about 10: 1. More preferred. The system preferably determines bandwidth allocation based on, for example, taking into account the current speed in a variable speed environment, taking into account the effect that the allocation has on the user's data communication charges. The present invention can cope with a change in data traffic, and can automatically learn and adapt to a condition that changes preferably. The present invention may be configured to take into account and / or modify a decision rule base and to consider current and other charges in order to provide broadband services as needed or desired while reducing or minimizing the cost to end users. have. The present invention provides a mechanism that is not vendor dependent, in order to implement and realize bandwidth allocation decisions. The same decision process can be run on hardware of different vendors without change. Since it is not so dependent on the vendor, the transition to new hardware can be performed with little or no modification to the determination system of the present invention, which makes the hardware upgrade easier. In this way, the vendor's investment in the described decision system is protected, and the new system is compatible with the processing procedure of the previous system. The present invention provides an intuitive GUI development environment and a language for creating and modifying rulebases used by the system. The development environment allows the vendor to integrate the decision algorithm work that is already being done into the rule base completely and easily. The rule base itself is preferably modular and can be reused. The present invention allows a rule base to be hot loaded into a router and executed during normal operation, i.e. without disassembling or rebooting the router and without stopping the data stream. Since the ability to hot load makes it possible to download frequently during testing, the present invention facilitates development and testing as well as changes to algorithms. In one embodiment, a single administrator console can control a relatively large number of widely distributed routers. Multiple administrator consoles can be used to manage the same group of routers that are locally and / or remotely connected to a particular location (eg, administrators at different replacement times can use different consoles). You can use the main backup and a third console for this purpose, or you can use a special console that is responsible for a separate part of the router. The present invention directly provides benefits to end users by facilitating the user's access to the telephone company and ISP, allowing the user some control over their ISDN usage. Although client-side applications can be used, client-side equipment is not required, so that a desirable degree of flexibility, openness, and future calibration is achieved. The system is preferably compatible with other vendor hardware on remotely connected devices that support BACP and MLPPP if sufficient memory and processing resources are available. The present invention provides a method of allocating bandwidth, such as bandwidth, such as ISDN, by using prediction of future bandwidth requirements, preferably not based on queue depth, but preferably based on data stream characteristics.

Many variations and modifications of the present system can also be used. Some features of the invention can be used without using other features. For example, it is possible to execute a data stream-oriented bandwidth allocation process based on a rule base without using an automatic learning process. The present invention uses the queue depth of “level of service” distribution methods, for example, when the system cannot identify the type of data in the data stream (or lacks time or other resources to do that identification). Such as combining data stream oriented bandwidth allocation with other methods. In some embodiments, for the purpose of allocating bandwidth to two or more data streams, it may be desirable to allow aggregation of their data streams (e.g., adding two or more co-existing data streams to add bandwidth). No, but adding bandwidth to the aggregated data streams might improve overall efficiency). The present invention can be used in an environment where there are a plurality of network transport media, or where there is only one network transport media such as, for example, Ethernet or ADSL network. In one embodiment, the present invention may be realized using a queue to allocate a virtual or software channel. Although the invention has been described in the context of ISDN realization, the invention has been described in other such communication systems or media including T1, frame relay, ATM, Ethernet, fiber optics and xDSL (eg, by providing and using virtual channels). Can be applied. The present invention can be used in connection with a network combining fiber optics, frame relays and Ethernet, and can also be used in connection with a network having only one type of medium (eg using a virtual channel or a software channel). Features such as modularization, real-time separation, byte code, and flag flagging are thought to contribute to the efficiency of execution, but it is also possible to realize flexible systems that do not include one or more of these. While certain features of the invention are described in the context of using an ISP, the invention may be implemented in many other contexts. For example, for remote network access, the system may reside on a remote access router (owned by a company whose external users use ISDN to connect to that router). The system can precisely allocate bandwidth to facilitate the communication, for example in a common environment (the data handling is sporadic and patterned). The present invention can be used in connection with connection between routers. For example, the point of sale systems at the satellite remembers the connection to the central site. The present invention makes it possible for a router, for example at a satellite location, to continue to be constantly connected to the headquarters via switched connections, even over long distance transport lines, without causing an increase in tolls. With such a system, low level throughput (price checks, credit card authorizations, etc.) can be done on narrowband D channels, which are always on, such as price file transfers, coupon downloads, store transactions, Higher level handling, such as summary uploading, utilizes the additional bandwidth required on demand. Various, including prioritizing the data stream, holding and queuing the data stream (or its packets), providing a firewall or other security function, and also providing a planning engine. The present invention can be used as a method.

Embodiments of the present invention may be provided using known artificial intelligence language castings such as C language and / or Prolog language. It is also possible to realize the invention using other languages and ways.

Although the present invention has been described in terms of preferred embodiments and by methods of specific variations and modifications, other variations and modifications may be used and the invention is defined by the following claims.

Claims (28)

A computer-implemented process for switching at least some packets in a telecommunications system to create a communication stream, Identifying at least one packet transmitted as a medium having a first bandwidth as a component of the stream; At least using the packet, in identifying the first characteristic of the stream, the characteristic at least partially predicts a data size of the stream, Identifying additional packets as components of the stream; Based on at least the first characteristic, determining whether to switch at least some of the additional packets to a second medium having a bandwidth greater than the first bandwidth. The process of claim 1, wherein identifying the at least one packet is based on at least one of source, destination, and port information included in the packet. The process of claim 1, wherein identifying the at least one packet is based on information in a data portion of the packet. 4. Process according to any of the preceding claims, wherein the first characteristic is obtained from packet header information. The process of claim 1, wherein the first characteristic is a type of data of the stream. The method of claim 5, wherein the data type, File transfer protocol type, GIF type, Streaming video types, Streaming audio types, Hypertext transfer protocol type, SMTP type, SNMP type and Process selected from H.323 types. The process of claim 1, wherein the first characteristic is a usage characteristic. Wherein said usage characteristic is associated with one or more periods for a given destination. 8. The process of claim 7, wherein the usage characteristic is related to a state of communication links in the telecommunication system. 10. The process of claim 9, wherein said state includes a current throughput. 10. The process of any of claims 1 to 9, wherein the first medium is a D channel of an ISDN line and the second medium is a bearer channel of an ISDN line. 10. The method according to any one of the preceding claims, wherein the telecommunications system comprises a medium having at least one D channel and a bearer channel and the determining step compares determining whether to initialize or stop the use of the bearer channel. Process. 13. The process of claim 12, wherein the medium is used to provide ISDN service or AO / DI service. 13. The process of claim 12 wherein the medium is used to provide a T1 service. 15. The process of claim 14 wherein the medium is used to provide a service other than a T1 service. In a telecommunications system for switching at least some data in a telecommunications stream, a computer-implemented process, In identifying the first characteristic of the stream, the characteristic at least partially predicts a possible data size of the stream; A determination step of determining, based on said first characteristic, whether to switch at least some additional data to provide another data transmission characteristic, said determination being performed using a first stored rule base; Automatically evaluating the validity of the decision step. 17. The process of claim 16, further comprising modifying the rule base based on the evaluating step. 18. The process of claim 17, wherein modifying the rule base is performed automatically to perform a computer-implemented self-learning telecommunications switching process. 19. The process according to any one of claims 16 to 18, wherein said determining step is carried out using a heuristic process. 19. The process according to any one of claims 16 to 18, wherein said evaluating step includes evaluating both service costs and levels. 20. The process according to any one of claims 16 to 19, wherein said evaluating step comprises evaluating global property bandwidth. 17. The process of claim 16, wherein said evaluating step includes a user evaluating based on specific criteria. The process of claim 16, wherein the various data transfer characteristics are selected from the group consisting of various bandwidth characteristics and other effective data transfer rate characteristics. A computer-implemented process in a telecommunications system that queues data streams, In identifying at least first and second different data types of the first and second input data streams, the input data streams are the first frequency of the data packets of the first data stream relative to the packets of the second data stream. Defining the Queuing at least the packets of the first and second data streams; Outputting at least one packets of said first and second data streams, said one of said data streams being output at a frequency different from said first frequency. A computer-implemented process in a telecommunications system that controls packet rates in a telecommunications system, At least, receiving a first request for data comprising a first data size indicator; Outputting a plurality of data requests having a second data size indicator different from the first data size indicator in response to the receiving. 27. The process of claim 25, further comprising calculating a calculated size of data requested to maintain speed control, wherein the second data size is less than the calculated data size and the first data size. In a telecommunications system, a process running on a computer that provides security, Identifying a data stream type of substantially all packets transmitted on the telecommunications system; Returning only packets that meet a predetermined criterion, wherein the predetermined criterion comprises a criterion relating to a data stream type of the packet. 28. The process of claim 27 further comprising returning a packet relating to at least a first data stream type only if a predetermined password has been received.