Multiplex communications – Communication techniques for information carried in plural... – Assembly or disassembly of messages having address headers
Reexamination Certificate
2001-02-21
2003-09-09
Ton, Dang (Department: 2666)
Multiplex communications
Communication techniques for information carried in plural...
Assembly or disassembly of messages having address headers
C370S392000
Reexamination Certificate
active
06618397
ABSTRACT:
FIELD OF THE INVENTION
The present invention generally relates to the field of electronic communications. More specifically, the present invention relates to communication protocol systems and methods used in such electronic communications.
BACKGROUND OF THE INVENTION
The Internet protocol (IP) is the standard protocol for carrying out data transmission over the Internet. Prior art
FIG. 1
shows an open system interconnect (OSI) model
100
that depicts the different layers of processing involved in IP data communication within a gateway or host computer. The model
100
includes application
102
, presentation
104
, session
106
, transport
108
, network
110
, data link
112
, and physical
114
layers. Each layer understands a certain communication protocol, which among other things contains a specific packet format. Each layer also employs a standard method of encapsulating and de-encapsulating packets received from upper and lower layers. When a layer receives a packet of data from an upper layer, that layer encapsulates the packet into a new packet conforming to the packet format the layer understands. The layer then passes the new packet to the next lower layer. When a layer receives a packet of data from a lower layer, the receiving layer retrieves (i.e., deencapsulates) the encapsulated inner packet and passes it to the next upper layer.
Prior art
FIG. 2
shows a group of diagrams
200
that illustrate encapsulation at various layers of model
100
as an example of UDP/IP over Ethernet, i.e., from the transport layer
108
to the network layer
110
and then to the data link layer
112
. At the transport layer
108
, a UDP packet
220
includes a UDP header
202
and data
210
. At the network layer
110
, the IP packet
230
includes the UDP packet
220
and an IP header
204
. And, at the data link layer
112
, the IP packet
230
is encapsulated in an Ethernet header
206
and trailer
208
, as an Ethernet frame
240
. The Ethernet frame
240
is transmitted to a physical network connection. It can be seen from FIG.
1
and
FIG. 2
, for each layer of encapsulation the packet size is increased, which means more bandwidth is consumed. For example, the Ethernet header
206
and trailer
208
together add 26 bytes. That is, for each IP packet transmitted, there will be 26 bytes of overhead in Ethernet framing.
FIG. 3
illustrates an example of prior art data communication between nodes, e.g., gateway/host A
310
and gateway/host D
340
, which includes transit through gateway B
320
and gateway C
330
. The data-link layer technologies employed by each connection may be different. For illustrative purposes, assume the direction of data communication is from gateway/host A
310
to gateway/host D
340
. For each frame of data received in a gateway (e.g., gateway
320
or
330
), the gateway needs to determine (referred to as routing) which gateway in the next hop to send the data, and may need to retrieve the IP packet from the frame and encapsulate the IP packet in a different data-link framing technology before relaying it to the next hop gateway. Such processing consumes computing power and memory and causes transmission delay. If data traffic is heavy in a gateway, the gateway may not be able to transmit the data as fast as it is received and network congestion and delays result due to excess contention for limited gateway resource and bandwidth.
IP header compression is a prior art technique that can reduce a packet's size and result in more efficient packet transportation. There are some Internet standard methods for IP header compression, such as IP/TCP header compression (RFC 1144) and IP/UDP/RTP header compression (RFC 2508). Header compression relies on many fields in the header being constant or changing seldomly in consecutive packets belonging to the same packet stream. Fields that do not change between packets need not be transmitted at all. To initiate compression of the headers of a packet stream, a full header carrying a context identifier (CID), is transmitted over the link. The compressor and decompressor store most fields of this full header in a context structure and the CID to be associated with the context structure. The context structure comprises the fields of the header whose values are constant and thus need not be sent over the link at all, or change little between consecutive headers so that it uses fewer bits to send the difference from the previous value compared to sending the absolute value. After context structure and its CID has been synchronized between the compressor and the decompressor, the compressor can then compress packet headers by computing the difference between the headers and the initial values stored in the context structure and encoding only the non-zero values of the difference. After receiving the compressed header together with the CID, the decompressor retrieves the context structure using the CID and decompresses the compressed header. Header compression is most effective for small packets where the overhead header is significant. The problem with IP header compression is that, the compressed packet is no longer a standard IP packet and it depends on the data-link layer to carry the compression information such that the receiving node can decompress the header and recover the original packet. This requires that the receiving node.must have a data-link layer direct connection with the sending node. Therefore, IP header compression has been applied only on a link-by-link basis. In today's public Internet, packet may traverse over many intermediate routers before reaching the receiving node. As shown in
FIG. 3
, packets originated from Node A
310
traverse over Node B
320
and Node C
330
before reaching Node D
340
. Therefore, IP header compression cannot be applied just between Node A
310
and Node D
340
.
IP payload compression (IPComp) is another prior art technique for improving packet transportation efficiency. IPComp is an Internet standard method (RFC-2393). IPComp reduces the size of IP payload before passing the IP packet to the data-link layer, and therefore increases the overall communication performance between a pair of communicating hosts/gateways (“nodes”). The IPComp protocol operates at the network layer
110
in the OSI model
100
, illustrated in FIG.
1
.
The compression processing of IP packets has two phases: compressing of outbound IP packets (“compression”) and decompressing of inbound IP packets (“decompression”). The compression processing must be loss-less, ensuring that the IP packet, after being compressed and decompressed, is identical to the original IP packet. Additionally, the compression processing must enforce a non-expansion policy, that is, if the compressed packet is larger than the original packet, the original packet will be transmitted.
The data link layer typically imposes a maximum transmission unit (MTU). For example, the Ethernet has a MTU of 1500 bytes. The non-expansion policy ensures the packet would not exceed the MTU, which would cause packet fragmentation and result in increased overhead. Each IP packet is compressed and decompressed by itself without any relation to s other packets (“stateless compression”), as IP packets may arrive out of order or not arrive at all. Each compressed IP packet encapsulates a single IP payload.
An original IP packet
400
is shown in prior art FIG.
4
A. IP packet
400
is shown in a compressed form
420
in
FIG. 4B
, in accordance with the prior art protocol IPComp. The compressed IP packet
420
contains a modified IP header
422
, an IPComp header
424
, and compressed.payload data
426
. The payload data
426
may be compressed using any known loss-less compression algorithm. The modified (indicated by the asterisk) IP header
422
shown in
FIG. 4B
contains a new protocol identification, which is used by the remote node to identify the packet as an IPComp compressed packet. The modified IP header
422
also contains new value of total length and header checksum for the compressed IP packet
420
.
As show
McDermott & Will & Emery
Provisionpoint Communications, LLC.
Ton Dang
Tran Phuc
LandOfFree
Group packet encapsulation and compression system and method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Group packet encapsulation and compression system and method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Group packet encapsulation and compression system and method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3042354