Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
2000-09-18
2004-10-05
Nguyen, Steven (Department: 2665)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S395100
Reexamination Certificate
active
06801530
ABSTRACT:
FIELD OF INVENTION
The present invention relates to the field of IP (Internet Protocol) networks and more specifically to an IP network, a Flow Classifier and a method for classifying IP flows in an IP network.
DESCRIPTION OF RELATED ART
Data networks for transferring electronic information are becoming increasingly widespread for the communication of many different types of data including text, graphics, voice and video data used with a computer. Such networks enable the interconnection of large numbers of computer workstations, telephone and television systems, video teleconferencing systems and other facilities over common data links or carriers.
Protocols between communicating computer systems are often implemented at multiple layers of a structural model. TCP/IP (Transport Control Protocol/Internet Protocol) and UDP/IP (User Datagram Protocol/Internet Protocol) are used to communicate across any set of interconnected networks. The TCP/IP and the UDP/IP software are both organised into four conceptual layers that 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. For example the physical layer uses various transport mediums, and the data link layer insures that the individual data packets are not corrupted during transmission between two directly connected systems. In TCP/IP the network and transport layers ensure that data packets arrive at the correct systems within a network and in a correct order. UDP/IP does not correct corrupted packets and does not ensure that the data packets arrive in a correct order. IP is a network protocol and TCP and UDP are transport protocols. Higher layers also talk to one another using various preselected protocols, for example RTP (Real time Transfer Protocol) which is a protocol for the transport of real-time data. Real-time data is a form of data where the correctness of the received packets depends not only on the logical result of the received data but also on the time at which the data arrives, such as audio and video. RTP is typically used over UDP. When transferring real-time data, using RTP and UDP protocols over an IP network the real-time data is broken up into frames. To keep track of details, such as frame sequence and timing, RTP attaches a header to each frame and hands over the resulting RTP frame (RTP header+frame) to UDP. UDP then adds its own header to the RTP frame=UDP datagram and hands it over to IP. IP then adds its own header to the UDP datagram=IP datagram. The resulting packet of data appears to be real-time data+RTP header+UDP header+IP header.
The specification documents of the Internet protocol suite, as defined by the IETF (Internet Engineering Task Force) and its steering group (the IESG), are published as RFCs (Requests for Comments).
In conventional IP networks, protocol layers operate in a rather isolated mode. For example, the transport layer offers the same service to all applications. Vice versa, applications operate independently of the characteristics, e.g. bandwidth and packet loss rate, of the underlying transport network.
A problem is that a too long time delay in situations of temporary overload in a node makes real-time data, such as audio or video, useless but does not cause corresponding damage to other types of data. This problem would be alleviated if real-time data were prioritised over non-real-time data. In this case and other cases where service differentiation is crucial, it is required that the server entity can distinguish between packets with different service demands. Often, one base of the differentiation is application category and/or different protocol format used by the flow. This assumes that the node in order to distinguish between packets with different service demands must know the type of application and/or protocol. For example the use of RTP protocol points out that the flow is a real-time flow and shall in case of temporary overload be prioritised over non-real-time flow.
Other examples of where service differentiation is required based on whether real-time data or other types of data is transferred are:
when an outgoing link of a node is a radio link, where the allocation of radio recourses depends on whether the transmitted data is real-time data or non-real-time data,
requesting the link layer to recover from errors, which is not required 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 lower-layer protocol units, a convenient way to identify the type of the encapsulated protocol is to use an explicit field in the header of the encapsulating lower-layer (e.g. IP) protocol. This is implemented in IP version 4 and IP version 6. This explicit field is the so-called TOS (Type Of Service) field and the network nodes that implement the differentiated services enhancements to IP use a codepoint in the IP header to select a PHB (Per-Hop Behaviour) as the specific forwarding treatment for that packet. This is described in the RFC 2598.
Thus, by reading this field, any unit that processes the packet flow can easily learn the type of the encapsulated protocol. Unfortunately, this explicit information is not commonly used.
The UDP header and TCP header do not carry any explicit information that can tell a receiving node that its payload contains real-time data.
U.S. Pat. No. 5,903,735 describes a method and apparatus of 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 prioritised over other data without minimal bandwidth requirements when transmitted. The higher priority is maintained by the plurality of nodes of the network path.
The problem is solved by bandwidth reservation through the path. This is, of course, a waste of bandwidth during those periods when less than the full bandwidth is required.
Therefore, what is further needed is a mechanism for classifying a flow as being a real-time flow or not, without explicit protocol format identifiers, without explicit flow description messages and without unnecessary waist of bandwidth.
SUMMARY OF THE INVENTION
The present invention relates to the requirement of differentiated service to real time packets and other type of packets, in an IP network. More particularly it relates to the problem with unacceptable latency in the network resulting in real-time packet being useless to the receiver.
A problem for a node is to know whether a received datagram comprises real-time data or not.
Accordingly, it is an object of the present invention to unravel the above-mentioned problems.
The aforesaid problems are solved by means of an IP network wherein a series of checkings in the headers of a flow classifies the flow as being a real-time flow or non-real-time flow.
The following scenario of classifying a flow describes the inventive concept of the present invention.
An aggregated flow within an IP network passes through a Flow Classifier before entering a node. The Flow Classifier distinguishes the aggregated flow into set of flows, each corresponding to an uni-directional packet stream from a single session. The Flow Classifier executes at least one of the following checkings on each flow:
checking payload size,
checking for static behaviour in header fields that are predictably constant if the flow is a real-time flow or
checking for incremental behaviour of header fields, which predictably increment if the flow is a real-time flow.
Based on these checkings, the Flow Classifier decides whether the flow is a real-time flow or non-real-time flow.
An advantage of the present invention is that the real-time flow will be faster transferred over the network.
Another advantage of the invention is that network recourses will be more efficiently used.
Yet an advantage of the present invention is that real-time data is identified independently of whether explicit desc
Brandt Harald
Castro Rui
Haraszti Zsolt
Nguyen Steven
Stevens Roberta
Telefonaktiebolaget LM Ericsson (publ)
LandOfFree
Communication system and method in a communication system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Communication system and method in a communication system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Communication system and method in a communication system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3328080