Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-05-28
2003-04-01
Hsu, Alpus H. (Department: 2665)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S401000, C709S247000
Reexamination Certificate
active
06542504
ABSTRACT:
FIELD OF INVENTION
The present invention relates to data communications. More specifically, it relates to the transmission of packet on a point to point communication link.
BACKGROUND OF THE INVENTION
Connection oriented communication links, such as point to point links, are an increasingly common feature of network infrastructures. One reason for this is the emergence of Voice over IP (VoIP), otherwise known as internet telephony. An increasing amount of local area network (LAN) and wide area network (WAN) traffic consists of VoIP packets.
VoIP typically combines several protocols in order to obtain the benefit of certain features of each type of protocol. A typical VoIP packet will include headers for the Internet Protocol (IP), User Datagram Protocol (UDP) and Real-time Transport Protocol (RTP). IP provides for unique addressing of source and destination hosts across multiple networks and routing of packets between hosts across multiple networks. UDP is a transport protocol that provides for a datagram or connectionless mode of communication for delivery of packets to a destination. RTP provides sequencing support for the transport of real-time data over packet switched networks. For more information regarding these protocols and internet telephony, see the Internet Engineering Task Force site at www.ietf.org.
It can be shown that uncompressed IP/UDP/RTP VoIP traffic carried through a point to point link, such as a Layer 2 Tunneling Protocol (L2TP) tunnel, can contain on the order of 1000% overhead from packet headers.
FIG. 1
illustrates a network architecture
50
where a prearranged L2TP tunnel
80
is the point to point link between network servers
62
and
72
.
FIG. 2
illustrates fields of a tunnel packet
90
sent over L2TP tunnel
80
to demonstrate the level of overhead that is incurred.
In architecture
50
, a Local Area Network (LAN)
60
includes a network server
62
that is connected to public IP network
70
and a remote access server
64
. Network server
72
is operated by an internet service provider (ISP) that permits end users, such as end user
74
, to access the public IP network
70
.
End user
74
desires a connection to a database residing on LAN
60
. While it is possible for end user
74
to dial directly into RAS
64
, where RAS
64
will authenticate end user
74
before permitting the user access to LAN
60
. However, the direct dial-in connection will often be a costly long distance call through the public switched telephone network (PSTN).
The end user
74
also has local dial-up access to network server
72
. Network server
72
is connected to network server
62
of LAN
60
through IP network
70
, but a security firewall is in place to prevent unauthorized access to LAN
60
. Due to the firewall, end user
74
would not be able to gain direct access to LAN
60
because the firewall would reject his connection attempt from network server
72
.
One solution is to provide end user
74
access from network server
72
to LAN
60
through a point to point link, such as L2TP tunnel
80
, that provides for secure access to LAN
60
from network server
72
through network server
62
.
L2TP tunnel
80
is a prearranged connection established by agreement between the company that operates remote access server
64
of LAN
60
and the ISP that operates network server
72
. End user
74
dials into network server
72
which recognizes end user
74
as a tunnel client by means of an authentication protocol or a special phone number reserved for tunnel clients. Assuming that the tunnel
80
between network servers
62
and
72
already exists, a new slot within the tunnel is assigned to end user
74
for transmission of packets across IP network
70
to network server
62
.
Each packet received from end user
74
includes Point-to-Point Protocol (PPP), IP INNER, Transmission Control Protocol (TCP) and File Transfer Protocol (FTP) headers along with the DATA field. Each packet from end user
74
is encapsulated in L2TP/UDP/IP headers by network server
72
before being forwarded to network server
62
. The resulting tunnel packet
90
is shown in FIG.
2
.
On the remote side, network server
62
strips the outer IP/UDP/L2TP headers from each tunnel packet
90
received through L2TP tunnel
80
and the resulting packet is presented to a “virtual interface” for PPP connections. The virtual interface is able to manage client connectivity using traditional mechanisms with respect to further authorization, protocol access, and packet filtering. By using the L2TP tunnel
80
, end user
74
is able to present packets to RAS
64
as if he were directly dialed-in to RAS
64
although the dial-up connection is, in fact, terminated at network server
72
.
As can be seen from tunnel packet
90
, the overhead involved with transmission of packets through tunnel
80
can dwarf the data payload of the packet. As noted above, the overhead of the packet header information can represent as much as 1000% of the size of the data field.
Since point to point links are increasingly common among many network infrastructures, it becomes increasingly important to efficiently use the bandwidth over these links. The point to point links mentioned here may be physically point to point, such as T1 lines, or may be virtual point to point links, such as IP tunnels, in which the data is switched across an established channel that may cross multiple networks. Note that a tunnel can follow a fixed route across networks or a variable route where tunneled packets can arrive at a destination endpoint through different paths across networks.
There are three commonly used conventional techniques to reduce the overhead associated with RTP traffic streams. Two methods deal with multiplexing many RTP streams between a pair of hosts into one RTP stream. These are described in An RTP Payload Format
for User Multiplexing
, J. Rosenburg, H. Schulzrinne, IETF Internet Draft <draft-ietf-avt-aggregation-00.txt>, November 1998; and
User Multiplexing in RTP payload between IP Telephony Gateways
, B. Subbiah, S. Sengodan, IETF Internet Draft <draft-ietf-avt-mux-rtp-00.txt>, August 1998. Although this kind of multiplexing results in reduced overhead because of a reduction in the number of packet headers at layers below RTP, the technique is limiting in that only traffic between a particular pair of hosts can be multiplexed together.
The other method deals with compressing IP/UDP/RTP headers over a low bit-rate link. This approach is described in
Compressing IP/UDP/RTP Headers for Low-Speed Serial Links
, S. Casner, V. Jacobson, IETF Internet Draft <draft-ietf-avt-crtp-05.txt>, July 1998. A limitation of this method is that its compression mechanism is quite complex. A remote access server terminating just a few low bit-rate links may be able to compress and decompress IP/UDP/RTP packets in real time using this mechanism, but more processing power would be required to keep up with the compression and decompression process if the links were at higher data rates, such as those on a voice network backbone (e.g. T1, T3, OC-3, etc.).
Furthermore, the low-speed method requires shared state between the two link terminators, which are typically gateways or other large network routing systems. This shared state is updated by each packet sent. If a packet is dropped along the link, the state will be inconsistent between the two link terminators. For a modem channel, which is lossless, albeit error-prone, this method works well. However, for a lossy channel, such as an under-provisioned packet-switched network, where packets can be lost during transmission, this method suffers when packets must be dropped in order to synchronize the state between the two link terminators. Also, the amount of shared state grows as the number of hosts at each terminator grows. For a network of large size, such as a voice network, this method will not scale well. Finally, the low-speed method provides no multiplexing mechanism.
Thus, the need remains for a method for efficiently transmitting packets across a poi
Borella Michael S.
Grabiec Jacek A.
Mahler Jerry J.
Sidhu Ikhlaq S.
3Com Corporation
Ho Duc
Hsu Alpus H.
McDonnell & Boehnen Hulbert & Berghoff
LandOfFree
Profile based method for packet header compression in a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Profile based method for packet header compression in a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Profile based method for packet header compression in a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3094277