TABLE 2


Table 2 depicts components from which
Traffic classes may be built. Note that the orientation
of the server (inside or outside) is specified. And as noted above, any
traffic class component may be unspecified, i.e. set to match any value.
Components of a Traffic Class Specifier

Inside
(Client or Server)	Global	Outside (Server or Client)

IP Address/Domain	TCP or UDP Service	IP Address/Domain Name
Name Port Number	e.g., WWW,	Port Number
MAC Address	FTP, RealAudio, etc.	MAC Address
	URI pattern for
	Web Service,
	MIME type for
	Web Service
	IPX Service
	SNA Service
	LAT Service
	IP precedence

FIGS. 2A and 2B depict representative allocations of bandwidth made by a hypothetical network manager as an example. In FIG. 2A, the network manager has decided to divide her network resources first by allocating bandwidth between Departments A and B. FIG. 2A shows the resulting classification tree, in which Department[0098]

A bandwidth resources

202 and DepartmentB bandwidth resources204 each have their own nodes representing a specific traffic class for that department. Each traffic class may have a policy attribute associated with it. For example, in FIG. 2A, the DepartmentA resources node202 has the policy attribute Inside Host Subnet A associated with it. Next, the network manager has chosen to divide the bandwidth resources of Department A among two applications. She allocates anFTP traffic class206 and a World Wide Webserver traffic class208. Each of these nodes may have a separate policy attribute associated with them. For example, in FIG. 2A, theFTP node206 for has anattribute Outside port20 associated with it. Similarly, the network manager has chosen to divide network bandwidth resources of Department B into an FTPserver traffic class210 and a World Wide Webserver traffic class212. Each may have their own respective policies.

FIG. 2B shows a second example, wherein the network manager has chosen to first divide network bandwidth resource between web traffic and TCP traffic. creates three traffic nodes, a[0099]

web traffic node

220, aTCP traffic node224 and adefault node225. Next, she divides the web traffic among two organizational departments by creating aDepartment A node226, and aDepartment B node228. Each may have its own associated policy. Similarly, she divides TCP network bandwidth into separate traffic classes by creating aDepartment A node230 and aDepartment B node232. Each represents a separate traffic class which may have its own policy.

All traffic which does not match any user specified traffic class falls into an automatically created default traffic class which has a default policy. In FIG. 2A, the default category is depicted by a[0100]

default node

205, and in FIG. 2B, the default category is depicted by adefault node225.

3.0 Automatically Classifying Traffic[0101]

3.1 Automatic Traffic Classification[0102]

Network traffic is automatically classified under existing classes, beginning with the broadest classes, an inbound traffic class and an outbound traffic class, in protocol layer independent categories. For example, a particular instance of traffic may be classified according to its transport layer characteristics, e.g., Internet Protocol port number, as well as its application layer information, e.g., SMTP. Characteristics such as MIME types may also be automatically identified. Standard protocols, such as, IPX, SNA, and services, such as, SMTP and FTP are recognized for automatic classification. Classification is performed to the most specific level determinable. For example, in select embodiments, non-IP traffic, such as SNA, may be classified only by protocol, whereas Internet Protocol traffic may be classified to the /etc/services level. Classification beyond a terminal classification level is detected and prevented. For example, in a select embodiment, a class matching “ipx” or “nntp” will not be further automatically classified.[0103]

3.1.1 Service Aggregates[0104]

A service aggregate is provided for certain applications that use more than one connection in a particular conversation between a client and a server. For example, an FTP client in conversation with an FTP server employs a command channel and a transfer channel, which are distinct TCP sessions on two different ports. In cases where two or three TCP or UDP sessions exist for each conversation between one client and one server, it is useful to provide a common traffic class i.e., the service aggregate, containing the separate conversations. In practice, these types of conversations are between the same two hosts, but use different ports. According to the invention, a class is created with a plurality of traffic specifications, each matching various component conversations.[0105]

3.1.2 Subclassification Under Specified Criterion[0106]

Subclassification of traffic into a tree is performed by matching the hosts and then searching for particular services. Traffic specifications are aggregate kinds of traffic for a traffic class, e.g., different components of FTP may reside under class FTP. Subclassification is performed by first locating a class that matches, and then performing finer grade matchings. Processing commences with a decision on what traffic is to be subclassified. A marker is placed in the match_all default node so that when match processing reaches the marker, the autoclassification processing depicted in[0107]

flowchart

403, determines that it has not found an existing class for the traffic being classified.

3.1.3 Default Suggested Policies[0108]

A default policy may be suggested or, in select embodiments, automatically applied, to a traffic class which has been automatically classified. Applying suggested or default policies for a new class at a user's option is described in a copending, commonly owned, U.S. patent application Ser. No.______ , entitled, “Method for Automatically Determining a Traffic Policy in a Packet Communications Network” (attorney docket number 17814-9.10), which is incorporated herein by reference in its entirety for all purposes.[0109]

3.1.4 Analysis of Data in Determining Traffic Class[0110]

In a preferable embodiment, classification can extend to examination of the data contained in a flow's packets. Certain traffic may be distinguished by a signature even if it originates with a server run on a non-standard port, for example, an HTTP conversation on port[0111]8080 would not be otherwise determinable as HTTP from the port number. Further analysis of the data is conducted in order to determine classification in instances where: 1) FTP commands are used to define server ports, 2) HTTP protocol is used for non-web purposes. The data is examined for indication of push traffic, such as pointcast, which uses HTTP as a transport mechanism. These uses may be isolated and classified into a separate class. Marimba and pointcast can be distinguished by looking into the data for a signature content header in the get request. Pointcast has URLs that begin with “/FIDO-1/.” Other applications in which protocol can be inferred from data include Telnet traffic. Both tn3270 and tn3270 E (emulation) may be detected by looking into data and given a different class. Telnet traffic has option negotiations which may indicate an appropriate class.

3.1.5 Identity of Traffic Based Upon Resource Creator's Class[0112]

A traffic class may be inferred from determining the identity of the creator of a resource used by the traffic class. For example, the identity of traffic using a certain connection can be determined by finding the identity of the creator of the connection. This method is used to detect Real Time Protocol (RTP) for point-to-point telephony, RTP for broadcast streaming, CCITT/ITU H320- telephony over ISDN, H323- internet telephony over the internet (bidirectional) and RTSP real time streaming protocol for movies (unidirectional).[0113]

3.1.6 Dynamic Ports[0114]

Applications having a well known port for a server may make use of dynamic ports. Some applications will send initial messages across a first connection, then negotiate a dynamic port for further conversation. During the existence of a connection, both endpoints are known. A check is made for two simultaneous connections to the same, non well-known port, at same time from different locations. This condition is indicative of a connection port for some application. Varieties of the dynamic port exist in applications. Certain dynamic ports are incorporated into a client. Others are fixed but not registered. Still others are negotiated during a protocol exchange, as for example in passive FTP.[0115]

3.2 Automatic Traffic Classification Processing[0116]

FIG. 3 depicts components of a system for automatically classifying traffic according to the invention. A[0117]

traffic tree

302 in which new traffic will be classified under a particular member class node. Atraffic classifier304 detects services for incoming traffic. Alternatively, the classifier may start with a service and determine the hosts using it. Aknowledge base306 contains heuristics for determining traffic classes. The knowledge base may be embodied in a file or a relational database. In a particular embodiment, the knowledge is contained within a data structure resident in memory. A plurality of savedlists308 stores classified traffic pending incorporation intotraffic tree302. In select embodiments, entries for each instance of traffic may be kept. In alternate embodiments, a copy of an entry and a count of duplicate copies for the entry is maintained.

FIG. 4A depicts a[0118]

flowchart

401 of processing steps for automatically classifying traffic. In astep402, a flow specification is parsed from the flow being classified. Then in astep404, the flow specification parsed from the flow instep402 is compared with the traffic specifications in each node of the classification tree. Rules are checked starting from most specific to least specific. In adecisional step406, a determination is made if traffic matches one of the classes being classified. If this is so, then in astep408, an entry is made in a list of identifying characteristics, such as protocol type (SAP), IP protocol number, server port, traffic type if known, MIME type, a time of occurrence of the traffic. In anoptional step410, duplicate instances having the same identifying characteristics are suppressed, in favor of keeping a count of the duplicates and a most recent time traffic with these identifying characteristics was encountered. In anoptional step412, a byte count of traffic of this type has been detected is included. Otherwise, the automatic classification has failed to determine a class and processing returns.

In a preferable embodiment, processing according to[0119]

flowchart

401 may execute on multiple instances of savedlist308.

3.2.1 Displaying Results to a User[0120]

In an optional step[0121]413 (not show), after the processing offlowchart401 completes or at periodic intervals or on demand, a list of traffic classes produced insteps402 through412 are displayed to a network manager. The list may be sorted by any well-known criteria such as: 1) most “hits” during a recent interval, 2) most recently-seen (most recent time first),3) most data transferred (bytes/second) during some interval, or a moving average. The user may choose an interval length or display cutoff point (how many items, how recent, at least B bytes per second, or other thresholds). The Network manager may then take some action (e.g. pushing a button) to select the traffic types she wishes to add to the classification tree. The display can be hierarchical, as depicted in lines (3) below:



	FTP	(3)

	FTP-cmd
	FTP-data

to host1

tcp

FTP

	FTP-cmd
	FTP-data

HTTP

	images
	java
	text

	port 9999

wherein the “port[0122]9999” entry is an inference corresponding to an application checking for repeated or simultaneous connections made to a specific port.

3.2.2 Interval Based Incorporation[0124]

In an alternative embodiment, at select intervals of time, non matching traffic is analyzed, and either 1) recognized and add to the tree, or[0125]2) for repeated attempts to request a server connection port that is not known, upon exceeding a certain threshold, a class for the port's traffic is created and added to the classification tree.

FIG. 4B depicts a[0126]

flowchart

403 of the processing steps for integrating traffic classes into a classification tree in an alternative embodiment. Processing steps offlowchart403 periodically at a defined interval of seconds, having a value of 30 in the preferable embodiment, incorporate newly classified traffic into the classification tree. In astep420, an instance of saved traffic is retrieved from the savedtraffic list308. Next in adecisional step422, the instance of saved traffic is examined to determine whether it is well-known (e.g. registered SAP, protocol type, assigned port number) and a name representing its type exists. If this is so then processing continues with a test of whether the saved traffic belongs to a service aggregate instep426. Otherwise, in astep423 the instance of saved traffic is examined to determine whether it appears to be a server connection port of an unregistered IP port (or a port that has not been configured). If this is not so then, processing continues with the next traffic class in the saved list instep420. Indecisional step426, the instance of saved traffic is examined to determine whether it belongs to a service aggregate. For example, an FTP session has one flow that is used to exchange commands and responses and a second flow that is used to transport data files. If the traffic does belong to a service aggregate, then in astep428, a traffic class is created which will match all components of the service aggregate. In afurther step425, a now traffic class is created to match the instance of saved traffic. The class may be flat or hierarchical.

In an optional step, a suggested policy is determined for the traffic class created in[0127]

step

425. Next, in adecisional step432, a limit is checked to verify that the number of automatically created classes has not exceeded a specified maximum.

step

425, a display of traffic classes, sorted by most recently used, most hits, number of bytes received during any interval, which is determined by a plurality of time stamps, is available on demand to a network manager. The network manager indicates that the traffic is to be added to the tree.

In a particular embodiment a threshold is employed to determine traffic for which a separate class should be added. A minimum usage threshold indicates whether a particular port has been used at least n times in the last s seconds. If traffic is well known, i.e., SMTP, it is added to a traffic class immediately, ie., threshold is equal to one, otherwise, the threshold is set equal to an arbitrary value, for example, eleven uses with not more than one minute between any two uses. A new class for traffic is given a generic name, e.g., Port99 traffic. Entries for traffic over a certain maximum threshold, for example one minute old, is discarded.[0129]

Traffic classes are created for any combination of the above mentioned categories. A flag is added to all traffic classes so created in order to indicate that it is the product of the auto classifier.[0131]

3.2 Command Language Interface[0132]

In a particular embodiment, function of the[0133]

classifier

304 is controlled by a command language interface. Table3 depicts a plurality of command language interface commands.

TABLE 3


setup autoclassify {on\|off}	To activate autoclassification for various
	classes to detect well-known protocols and
	services:
class auto <tclass>	To turn on autoclassification under a class
{inside\|outside\|both}	To detect services with the host on the
	inside, the outside, or both directions.
class auto <tclass> off	To turn off use

The new classes have names in the format of lines (4) below:[0134]



	<direction>_<service>_<parent>or	(4)
	<direction>_port_<number>_<parent>or
	<direction>_<service>_<portnum>_<parent>

where <direction> is either “inside” or “outside” for TCP/UDP services or “auto”for others.[0135]

If a well-known service on a non-standard port (e.g. HTTP on 8080) is detected, a name in the last format will be created, assuming no previous class match.[0136]

If a heretofore unknown server-connection port appears to be “well used”, an entry of the second type is created. The threshold for creation is currently 11 hits with no more than 1 minute (granularity of checking is at least 30 seconds between running successive autoclassification processes) between any two hits. For example, see lines (5) below:[0137]



	inbound/inside/ftp	(5)
	outside_http_inbound
	auto_sna_inbound
	inside_port_505_luna
	outside_pointcast_8888_inbound

The “class show” command will now show an ‘D’ in the flags for classes currently being autoclassified.[0138]

3.3 Syntax of Traffic Specifications[0139]

Flow specifications and traffic specifications have an inside service field and an outside service field. Each will have values of SVC_UNKNOWN (0), SVC_CLIENT (1), or a number greater than 1, which is the service index, an index into the global table gServiceTable. If a type of service is known for a connection, the service field at a particular side will be set to SVC_CLIENT and the service field at the opposite side will be the index into gServiceTable. If a type of service is not known for the traffic, both inside service field and outside service field will be SVC_UNKNOWN. A person of reasonable skill in the art will appreciate that other embodiments for the table, such as representing the information contained therein as text strings or by any one of a plurality of possible encoding schemes, are realizable without departing from the present invention.[0140]

Therefore, a traffic specification can have “outside service:http” (or just “outside HTTP”) which is different than “outside tcp:80”. The first will match HTTP on any port while the second will match anything on port[0141]80 (including pointcast and marimba).

Specifying a traffic specification tspec “service:<agg>” returns traffic specifications for various traffic belonging to the service. Specifying “class new inbound cdls outside dls” is the same as “class new inbound cdls outside service:dls-wpn” and “class tspec add cdls outside service: dls-rpn”. Most auto-recognized services will create a class that encompasses all the pieces.[0142]

Network managers need not be aware of services which are known to be derivative of others, e.g., pointcast and marimba are special cases of HTTP and tn3270 is a special case of Telnet, in order to work with the system.[0143]

4.0 Conclusion[0144]

In conclusion, the present invention provides for an automatic determination of a policy for a packet telecommunications systems wherein bandwidth is allocated to requesting flows according to automatically determined application requirements. An advantage of traffic classification techniques according to the present invention is that network managers need not know the technical aspects of each kind of traffic in order to configure traffic classes. A further advantage of the present invention is that traffic classes may include information such as a MIME type for web traffic.[0145]

Other embodiments of the present invention and its individual components will become readily apparent to those skilled in the art from the foregoing detailed description. As will be realized, the invention is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive. It is therefore not intended that the invention be limited except as indicated by the appended claims.[0146]