Ip flow classifier for distinguishing real-time flows from non-real-time flows

SWEDEN (12) PATENT WRITING (13) C2 (ii) 521 463

<img file="SE521463C2_D0001.tif" />

(19) SE (si)

International class ⁷

H04L 29/06, 12/56

PATENT AND REGISTRATION (45) (41) (22) (24) (62) (86) (86) (83)

Patent issued 2003-11-04

Application widely available 2001-03-21 The patent application was filed on 9/9/1999

Running day 1999-09-20

Tribal application number

International filing day

Filing date for European patent application

Deposit of microorganism (21) Patent Application Number 9903390-4

Application received as:

Swedish patent application completed international patent application with number □ converted European patent application with number (30) Priority information (73) (72) (74) (54)

Assignee

INVENTOR

AGENT

NAME

Telefonaktiebolaget LM Ericsson, 126 25 Stockholm SE Harald Brandt, Hägersten SE, Zsolt Haraszti, Kista SE, Rui Castro, Älvsjö SE

Dr. Ludwig Brann Patentbyrå AB

Classifier in an IP network with means to determine whether a transmitted flow is a real-time flow or not (56) (57)

CALLED PUBLICATIONS: - - SUMMARY:

The present invention relates to the need for differentiated service for real-time packets and other types of packets in an IP network. More specifically, this concerns the problem of unacceptable delay in the network, which results in real-time packets becoming unusable for the receiver. One problem for the node is knowing whether or not a received datagram contains real-time data. An aggregated flow in an IP network passes through a flow classifier before arriving at the node. The flow classifier divides the aggregated flow into sets of the river where each flow corresponds to a unidirectional packet stream from a single session. The flow classifier performs at least one of the following studies:

- examination of the payload size,

- exploration of static behavior in the header fields that is predictably constant if the flow is a real-time flow, or

- examination of incremental behavior in the header fields, which is predictable if the flow is a real-time flow.

Based on these studies, the flow classifier decides whether the flow is a real-time or non-real-time flow.

<img file="SE521463C2_D0002.tif" />

The numbers in brackets indicate international identification code, INID code. Letters in clamps indicate international document code.

521 463

SUMMARY

The present invention relates to the need for differentiated transmit to real-time packets and other types of packets in an IP network. More specifically, this concerns the problem of unacceptable delay in the network, which results in real-time packets becoming unusable for the receiver. One problem for the node is knowing whether or not a received datagram contains real-time data. An aggregated flow in an IP network passes through a flow classifier before arriving at the node. The flow classifier divides the aggregated flow into a set of flows where each flow corresponds to a unidirectional packet stream from a single session.

The flow classifier performs at least one of the following studies:

- examination of the payload size,

- exploration of static behavior in the header fields that is predictably constant if the flow is a real-time flow, or

- investigation of incremental behavior in the header fields, which is predictably incremental if the flow is a real-time flow.

Based on these studies, the flow classifier decides whether the flow is a real-time flow or a non-real-time flow.

(Publication figure: Figure 3)

521 463 f

FIELD

The present invention relates to the field of technology (Internet Protocol) networks and more particularly to an IP network, a flow classifier and a method for classifying IP flows into an IP network.

BACKGROUND OF THE ART

Data networks for the transmission of electronic information are becoming increasingly widespread for data communication of many different types such as text, graphics, voice and video data used in computers. Such networks allow interconnection zv a large number of computer workstations, telephone and m systems, video conferencing systems and other facilities over shared data links or carriers.

Protocols between communication data systems are often implemented in multiple layers according to a structured model. TCP / IP (Transport Control Protocol / Internet Protocol) and UDP / IP (User Datagram Protocol / Internet Protocol) are used to communicate between different types of interconnected networks. TCP / IP and UDP / IP software are both arranged in four conceptual layers, which are built on a fifth layer, the hardware. The highest layer is the application layer followed by the transport layer, the network layer, the data link layer and the physical layer, which is the hardware layer. E.g. the physical layer uses different transport media and the data link layer ensures that the individual data packets are not destroyed during the transfer between directly connected systems. In TCP / IP, the network and transport layers ensure that data packets arrive at the right system in a network and in the right order. UDP / IP does not correct corrupted packets and does not guarantee that data packets arrive in the correct order. IP is the network protocol and TCP and UDP are transport protocol. Higher layers also talk to each other using a number of preselected protocols, e.g. RTP (Real Time Transfer Protocol), which is a protocol for transmitting real-time data. Real-time data is a form of data where the order in the received packets depends not only on the logical result of the received data packets but also on

521 463 the time when data packets arrive, such as audio and video. RTP is usually used over UDP. When real-time data is transmitted over an IP network and RTP and UDP protocols are used, the real-time data is broken into frames. To keep track of the details, such as frame sequence and timing, RTP puts a so-called header on each frame and passes the resulting RTP frame (RTP header + frame) to the UDP. UDP then adds its own header to the RTP framework - UDP datagram and passes it to IP. IP then adds its own header to the UDP datagram = IP datagram. The resulting packet of data then becomes real-time data + RTP header + UDP header + IP header.

The specification document in the Internet Protocol series, as defined by the Internet Engineering Task Force (IETF) and its steering group (IESG), is published as Requests for Comments (RFCs).

In conventional IP networks, protocol layers operate in a fairly isolated manner. E.g. the transport layer provides the same sender for all applications. Vice versa, the applications operate independently of the nature of the underlying transport network such as e.g. bandwidth and packet tap speed.

One problem is that too long a delay in situations of temporary overload in a node makes real-time data, such as audio or video, unusable but does not cause the same damage to other types of data. This problem would be mitigated if real-time data was prioritized over non-real-time data. In this case and other cases where the difference between the sende is critical, there is a need to late^rThe er unit can differentiate between packages with different types of send needs. One type of differentiation used by the flow is the application (application) category and / or different protocol formats used. This requires that the node in order to distinguish between packets with different send needs needs to know the type of application and / or protocol. E.g. the use of RTP protocols indicates that the flow is a real-time flow and, in case of temporary overload, should be prioritized over non-real-time flow.

Other examples where send differentiation is needed based on whether real-time data or other types of data are being sent are:

- When an outbound link from a node is a radio link where the allocation of radio resources depends on whether the transmitted data is real-time or non-real-time data,

521 463 i 'i J::. 1

- Order the link layer for incorrect correction, which is not needed for real-time data but for other types of data, and

- Access to a server or to a network.

When protocol units are encapsulated in other camp layer protocol units, a simple way to identify the type of encapsulated protocol is to use an explicit field in the header of the encapsulated camp layer (e.g., IP) protocol. This is implemented in IP version 4 and IP version 6. This explicit field is a so-called The TOS (Type Of Service) field and the network nodes that implemented the differential service enhancements to IP use a code point in the IP header to select a PHB (Per-Hop Beha \ dour) as the specific forwarding processing for this packet. This is described in RFC 2598. Thus, by reading this field, any entity that processes the packet flow can read out the type of the encapsulated protocol easily. Unfortunately, this explicit information is not common.

The UDP header and TCP header do not carry any explicit information that can tell a receiving node that its utility data contains real-time data.

U.S. Pat. No. 5,903,735 describes a method and apparatus for transmitting time-critical messages over a network path having a plurality of nodes. The data is classified as minimal bandwidth data in the first node and prioritized over other data without minimal bandwidth requirement when sent. The higher priority is maintained by the nodes along the way.

The problem is solved with bandwidth reservation along the way. This is of course a waste of bandwidth during those periods when less than full bandwidth is utilized.

Therefore, what is further needed is a mechanism for classifying a flow as being real-time flow or not without explicit protocol format identifiers, without explicit flow description messages and without unnecessary waste of bandwidth.

SUMMARY OF THE INVENTION

Pre-existing discoveries relate to the need for differentiated service to the real-time network and other • OO II O ------- - - - In types of packets in an IP network. More specifically, it addresses the problem of unacceptable delay in the network, which results in real-time packets becoming unusable for the receiver.

521 463

One problem for a node is knowing whether or not a received datagram contains real-time data.

Therefore, the object of the invention is to overcome the above problems.

The aforementioned problems are solved through an IP network in which a series of investigations of the headers of a flow classify the flow as being real-time or non-real-time flow.

The following scenario of classifying a flow describes the inventive concept of the present invention.

An aggregated flow in an IP network passes through a flow classifier before the flow reaches the node. The flow classifier divides the aggregated flow into different sets of flows, where each set corresponds to a unidirectional packet stream from a single session. The flow classifier performs at least one of the following examinations of each flow:

- examination of the payload size,

- study of a static behavior in a header field that is predictably constant if the flow is a real-time flow, or

- Examination of some header fields if they are incremental, increasing predictably if the flow is a real-time flow.

Based on these studies, the flow classifier decides whether the flow is a real-time or non-real-time flow.

An advantage of the present invention is that the real-time flow can be transmitted faster over the network.

Another advantage of the present invention is that the network resources will be used more efficiently.

521 463 PKUULj- 1 / -3

A further advantage of the present invention is that real-time data can be identified independently of^r whether explicit description (eg by signaling) of real-time data flow is available or not.

A further advantage of the present invention is that when used in radio access networks to detect IP packet flows with real-time needs, the resource allocation can be optimized. This improves the network usage and service quality that the user will notice.

Further uses of the present invention will be apparent from the detailed description below. However, it should be understood that specific examples in connection with the detailed description of preferred embodiments are purely illustrative, as a variety of changes and adaptations fall within the scope and spirit of the invention, as will be apparent to those skilled in the art.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 shows an RTP header.

Figure 2 shows an overview of a ΪΡ network according to the invention.

Figure 3 shows a flow chart of the general method according to the invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

An RTP header will now be described in accordance with RFC 1889 section 5, to facilitate the understanding of preferred embodiments. The RTP device header has some predictable features that allow you to test a UDP stream and tell if it contains RTP frames or not. However, the invention is not only applicable to RTP feeds, it is applicable to other protocol formats which have similar predictable header behaviors.

The format of the RTP header is shown in Figure 1. The fields have the following meaning:

521 463

Version V: 2 bits

This field identifies the version of RTP. The version defined by this specification is two (2).

Padding P: 1 bit

If the fill bit is set, the package contains one or more additional fill octets and at the end, which is not part of the payload. The last octet of fill-in contains a calculation of how many fill-octets to be ignored. Fill-in may be needed by some encryption algorithms with fixed block sizes or to carry a number of RTP packets in a lower-layer protocol data unit.

Extension (X) in bit

If the extension bit is set, the fixed header is followed by exactly a header extension with a format defined in section 5.3.1 of the RFC mentioned above.

CSRC counter CC: 4 bits

The CSRC (synchronization source) counter contains the number of CSRC identifiers that follow the fixed header.

Marker (Marker) Μ: 1 bit

The interpretation of the marker is defined by a profile. It is intended to allow significant events such as frame interfaces to be highlighted in the packet stream. A profile can define additional selection bits or specify that there is no marker bit by changing the number of bits in the payload type field. This is further described in section 5.3 of the RFC mentioned above.

Payload type PT: 7 bits

This field identifies the format of the RTP payload and determines its interpretation of the application. A profile specifies normal static mapping of payload type codes for payload format. Additional payload type codes can be dynamically defined by the non-RTPii 3 1 RFC mentioned above. An introductory _____ „: ιι._{Λ &lt;}. · Λ ~ ____ lllCUCi, VlifkCL al VLLLiUgdlL ULSTUlVLL in ÖCIKUKJ setting audio and video standard mappings is specified in the InternetDraft draft-ietf-avt-profile, and can be expanded in future releases of Assigned Numbers

521 463

RFC. An RTP transmitter broadcasts an RTP payload type at any time. This field is not intended for multiplexing of separate media streams.

Sequence number SN: 16 bits

The sequence number increases by one for each data packet sent, and can be used by the receiver to detect packets that have disappeared and to save packet sequences. The first value of the sequence number is random (unpredictable) to make encryption attacks more difficult, although the source itself is not encrypted because the packets can flow through a translator that does.

Timestamp TS: 32 bits

The timestamp reflects the sampling time of the first octet in an RTP data packet. The sampling time must be derived from a clock that increases monotonically and linearly in time to allow synchronization and jitter calculations (see further in section 6.3.1 of the RFC mentioned above). The accuracy of the clock must be sufficient for the desired synchronization accuracy and for measuring packet arrival jets (one tick per video is usually not enough). The clock rate depends on the format of the data carried as payload and is statically specified in the profile or payload format specification that defines the format or can be dynamically specified for payload format defined by non-RTP means. If the RTP packet is generated periodically, the nominal sampling time determined from the sampling clock must be used, not a reading of the system clock. As an example of constant-speed sound, the timestamp clock increases by one for each sampling period. If an audio application reads blocks covering 160 sampling periods from the input device, the timestamp clock increases by 160 for each such block, regardless of whether the block is sent in a packet or dropped as silent.

Synchronization source SSRC: 32 bits

The SSRC tag identifies the synchronization source. This identifier is selected at random for the purpose of no two-synchronization source within the same RTP session having the same SSRC identifier. An algorithm example to generate a random identifier is presented in Appendix A.6 of the above RFC. Although the reliability of multiple sources selecting the same identifier is low, all RTP implementations must be prepared to

521 465 detecting and resolving collisions. If a source changes its source transport address, a new SSRC identifier must also be selected to avoid being interpreted as a looped source.

Contributing source CSRC list: 0-15 pieces, 32 bits in each

The CSRC list identifies the contributing sources of payload included in this package. The number of identifiers is given by the CC field. If there are more than 15 contributing sources, only 15 can be identified. The CSRC identifier is inserted by mixers using SSRC identifiers from contributing sources. E.g. for audio packets, the SSRC identifiers from all sources are mixed together to form a packet area that is listed, allowing proper speaker indication at the receiver.

Figure 2 shows the preferred embodiment of an IP network 200 in which different transmitters are differentiated based on whether or not the transmitted flow 201, 202, 203 is real-time flow. The IP network 200 includes interconnected nodes 204 representing e.g. changers, routers and hosts. An aggregated flow is defined as a mix of all different flows transmitted over a point in the IP network 200, each flow corresponding to a unidirectional packet stream of IP datagrams from a single session. Aggregated flows are transmitted in the IP network 200 between the nodes 204. The IP network 200 also includes a flow classifier 205 through which an aggregated flow 201, 202 passes before entering the node 204. A flow classifier may also be co-located in a node 204.

The flow classifier 205 has means 206 for dividing the incoming aggregate flow 201 into different sets of flows, each flow corresponding to a unidirectional packet stream of IP datagrams from a single session. This breakdown allows the flow classifier 205 to view one flow at a single session at a time.

The flow classifier 205 also has means 207 for examining the payload size of the transport layer datagram of a packet in a flow associated with a specific session, and also means 213 for examining whether the payload size of the transport layer datagram is larger than the smallest possible datagram of a specific session containing If it is, it may be a real-time flow, but if it is not, it is not a real-time flow. E.g. investigate whether the UDP payload is greater than the smallest possible RTP frame.

521 463

The flow classifier 205 also has means 208 to look at a number of consecutive data packets in the flow of the specific session and examine by checking the static behavior in the header fields, which are predictably constant if the flow of the specific session is a real-time flow. E.g. check if the header fields, which are meant to be constant in consecutive RTP frames in a session, are constant in the examined flow. Examples of constant RTP header fields are the Version V field and the payload PT field. Payload Type The PT field tells you what is inside the RTP, such as whether it is the GSM codec, whether it is speech or anything else. These are constant during the session if it is a real-time flow. If these header fields in the studied flow are not constant, it is a non-real time flow.

The flow classifier 205 also has means 209 for viewing a number of consecutive data packets in the flow of a specific session and examining incremental (increase) behavior in the header fields, which field predictably increases if the flow of the specific session is a real-time flow. E.g. investigate in the possible RTP header (you want to determine if it really is an RTP header because then you know it is a real-time flow) if the fields that are expected to increase, according to the above-mentioned RFC 1889, increase. Examples of increasing RTP header fields are the sequence number SN field and timestamp TS field. If these header fields that are expected to increase in the surveyed flow do not increase, it is a non-real-time flow.

The flow classifier 205 has additional means 212 to examine whether the value of the header fields in an application datagram satisfies constraint restrictions on the header of an application datagram including real-time data, e.g. and an RTP frame. If the constraint restrictions are not met in the studied flow, it is not a real-time flow.

The flow classifier 205 has additional means 210 for deciding whether the flow is a real-time flow or not, based on previous studies. When looking at a number of consecutive data packets in a feed, one must take into account that one or more packets may be missing.

The flow classifier 205 has means 211 for reporting the decision whether the flow is a real-time flow or not to the node 204.

521

<img file="SE521463C2_D0003.tif" />

In one embodiment of the present invention, an output link 203 constitutes the node

204 a radio link and the node 204 has means 214 for allocating radio resources based on whether the flow is a real-time flow or not.

In another embodiment, node 204 has means 215 to make a request to the link layer to error protect if the flow is a non-real-time flow or not to fail-protect if the flow is a real-time flow. There is no need to correct errors when transmitting real-time data.

In yet another embodiment, node 204 forms a switch. The switch has means 216 for prioritizing a real-time flow over a non-real-time flow when switching, e.g. in situations of temporary overload.

In yet another embodiment, the node 204 is a router. The router has means 216 to prioritize real-time flow over non-real-time flow during routing, e.g. in situations of temporary overload.

Figure 3 shows a flowchart of a possible scenario for distinguishing real-time flow from other types of flows in a stream of IP data packets in an IP network 200.

The IP network 200 includes interconnected nodes 204. Aggregated flows are sent in the IP network 200 between the nodes 204. The node 204 has an incoming aggregate flow of IP datagrams. The incoming aggregate flow is split 300 into different sets of flows, each of which flows corresponds to a unidirectional packet stream from a single session. This allows you to watch one stream from one session at a time.

The method includes at least one of the following studies:

Examination of payload size 301 of the transport layer datagram of a packet in a flow associated with a specific session. In one embodiment, it is also possible to investigate whether the payload size of the transport layer datagram is larger than the smallest possible datagram of a specific session containing real-time data, e.g. investigative

521 463 if the UDP payload size is larger than the smallest possible RTP frame. If it is, it is not a real-time flow.

Examining the header fields of an application datagram, if the value of the fields satisfies constraint restrictions 302 in the header of an application datagram including real-time data, e.g. and an RTP frame. If the constraint restrictions are not met in the studied flow, it is not a real-time flow.

- A number of consecutive data packets in the flow of a specific session are looked at, where the static behavior 303 in the header field is examined, which fields are predictably constant if the flow of the specific session is a real-time flow. E.g. examines whether the header fields, which are expected to be constant in consecutive RTP frames in a specific session, are constant in the polled flow. Examples of constant RTP header fields are version V fields and payload PT fields. Payload type PT field talks about what is inside the RTP so if it is from a GSM encoder, whether it is voice or something else. These are constant during the session if it is real time. If these header fields in the studied flow are not constant, it is not a real-time flow.

- A number of consecutive data packets in the flow of a specific session are looked at, where the incremental behavior 304 of header field is investigated, this is predictably increasing in a flow of a specific session is a real-time flow. E.g. examination of the possible RTP header, if the fields that are expected to be increasing, according to the aforementioned RFC 1889, increase. Examples of increasing RTP header fields are sequence numbers SN fields and timestamps TS fields. If these header fields that are expected to increase in the surveyed flow do not increase, it is not a real-time flow.

The method comprises the further step of deciding whether the flow is a real-time flow or not, based on the aforementioned studies.

The surveys performed are each resulting in either non-real-time flow or possible real-time flow. If any of the survey steps above show that it is non-real-time data, no further investigation needs to be done. An example of how these investigations can go will now be described:

521 463

First, we examine whether the payload size of the UDP payload is greater than the smallest possible RTP frame. If not, the flow is classified as non-real-time flow. If it is, it can be a real-time flow and further investigations must be done.

If further investigations need to be done, an examination of the value of the header fields in an application datagram follows the constraint restrictions 302 of an RTP header. If the restriction restrictions are not met in the investigated flow, the flow is classified as non-real-time flow. If they are met, it can be a real-time flow and further investigations are necessary. In this example, the next step is to examine whether the header fields, which are expected to be constant in consecutive RTP frames in a session, are constant in the examined flow. If they are not constant, the flow is classified as a non-real-time flow. If they are constant, there is a possible real-time flow and further investigations are needed.

In this case, the possible RTP header is investigated if the fields, which are expected to increase in consecutive RTP frames according to the aforementioned RFC 1889, are increased. (That is incremental behavior.) If these header fields are non-incremental, the flow is classified as a non-real-time flow. On the other hand, if these header fields increase, the flow is classified as a real-time flow.

When looking at a number of consecutive data packets in a flow and examining the behavior of the increase, one must take into account that one or more packets may be missing.

In one embodiment, the method includes a step reporting the decision whether or not the flow is a real-time flow to the node 204.

521 ο

/3