Multiplex communications – Data flow congestion prevention or control – Control of data admission to the network
Reexamination Certificate
1999-11-30
2003-06-10
Yao, Kwang Bin (Department: 2664)
Multiplex communications
Data flow congestion prevention or control
Control of data admission to the network
C370S395420
Reexamination Certificate
active
06577596
ABSTRACT:
BACKGROUND
The present invention relates to multiplex communication systems for transferring information in packets and more particularly, to scheduling and header compression of packets in a multilayered network architecture.
Modern communications networks carry increasing amounts of packet traffic which is associated with real-time voice, video, and related data. The Internet, for example, is seeing many new applications which take advantage of what is a relatively less costly alternative to conventional telephone call connections for sending a variety of data including real time voice and video. Trends toward real time applications over the Internet are driven in part by increasingly powerful computers being installed in private homes and the proliferation of the Internet as a focal point for various on-line activities such as holding voice conversations, listening to music, watching video clips, and the like. Unlike Internet communications which occur between computers on high bandwidth commercial connections, bandwidth in a typical home is limited by connectivity constraints imposed by modem speed, line quality, and the like.
Further compounding the basic problem of limited bandwidth, is the limitation on the amount of actual information transmitted as a result of packet overhead due to protocol headers. Basic Internet protocols were developed primarily for making sure that packets were delivered accurately end to end at a time when little consideration was paid to real time issues.
Three layer interface architectures including protocols such as X.25, for example, were developed for controlling transfer at the lower levels while higher layer protocols were developed to control more sophisticated functions (see, “Open Systems Interconnect (OSI)—New International Standards Architectures and Protocols for Distributed Information Systems,” special issue, Proceedings of the IEEE, H. C. Folts and R. des Jardins, eds., vol. 71, no. 12, December 1983). According to the design philosophy, lower layer functions were contemplated to be “transparent” to higher layer functionality and thus much of what can be accomplished at the lower layers is limited only by the ability of lower layer hardware and software to preserve that transparency. At the lowest layer, the Physical Layer, a protocol specification governs the physical connection between devices, such as, for example, the X.21 protocol. Next, the Data Link Layer specifies the protocol for, for example, accepting packets from higher layers and placing them into, for example, HDLC frames for transfer across the Physical Layer. The Data Link layer further may accept framed information from the Physical Layer and unpack it for transfer up to the Network Layer. At the Network Layer, or packet layer, multiple logical connections may be established and addresses attached to packets based on several assumptions including that successful end to end delivery is not guaranteed, that orderly delivery is not guaranteed, and that packets or “datagrams” are delivered one at a time each containing information such as destination address, and the like.
It is important to note that while various lower layers are discussed herein, datagrams from higher layers may form the input to a Network Layer process or system, which in turn provide input to successively lower layers, and eventually to the destination. Higher layer datagrams input to a Network Layer entity may be input from, for example, a Transport Layer process or system. A typical and well know transport layer protocol is the Transport Control Protocol (TCP) although other Transport Layer protocols are known and used. In particular, the User Datagram Protocol (UDP) may often be used as a Transport Layer protocol. UDP is a protocol which defines a connectionless datagram service. A Transport Layer process or system implementing UDP may produce self-contained data packets which include destination routing information.
A ubiquitous protocol for Network Layer communications over the Internet is the Internet Protocol (IP). The IP specification includes an enumeration of fields associated with the IP header which fields contain information about an associated packet including information for determining how the packet should be delivered. The IP header fields will be described in greater detail herein below. For a more complete understanding of the contents of the IP header, see “Internet Protocol Specification”, E. J. Postel, SRI International, Menlo Park, Calif., September 1981, RFC791.
For Data Link Layer communications, Point-to-Point-Protocol (PPP) has become a dominant protocol. PPP includes three main components: a method of encapsulating multi-protocol datagrams, a datagram being a unit of transmission in the network layer (such as IP), a link control protocol (LCP) for establishing, configuring and testing the data-link connection, and a family of network control protocols (NCP) for establishing and configuring different network-layer protocols.
PPP is designed to transport packets between two so-called peers, i.e. the two ends of a link conforming to the protocol. Accordingly, the LCP may be used to agree upon the encapsulation format options, handle varying limits on sizes of packets, detect configuration errors, and terminate the link. Other optional facilities are the authentication of the identity of its peer on the link, and the determination when a link is functioning properly and when it is failing. PPP links-provide full-duplex simultaneous bidirectional operation. A definition of PPP may be found in the Networking Group Request for Comments RFC 1661, “The Point to Point Protocol” editor W. Simpson, July 1994.
Communication across a link established using PPP is accomplished such that a datagram associated with a protocol may be encapsulated into one or more frames. A frame, as described above, may include a header and/or a trailer, along with some number of units of data. However, it is conventional that an entire packet is mapped into a frame. Conventional framing breaks down however during conditions of heavy network congestion where fragmentation methods may be used to improve flow control management. Such congestion has arisen due to, among other factors, the increase in traffic caused by increased numbers of greater bandwidth connections provided by, for example, multilink service. Since both basic and primary rate ISDN, for example, allow for multiple simultaneous channels between systems to allow for bandwidth on demand, problems associated with such services must be addressed. Congestion giving rise to latency may be a particular problem for real time data such as voice or video, VoIP, Telnet, and the like. Such real time data formats have little or no tolerance to packet latency, jitter, packet reordering and related problems. Problems associated with the multilink environment only amplify the unique real time packet data requirements.
To ease congestion in the multilink environment, one solution known as Link Fragmentation and Interleaving (LFI) is proposed in the White Paper entitled “Cisco IOS™ Software Quality of Service Solutions”, Apr. 8, 1999, by Cisco Systems. In LFI, delay and jitter are reduced by breaking up large datagrams and interleaving time sensitive packets with the resulting packet fragments. LFI is contemplated for relatively low speed links where serialization delay is the predominant delay factor. LFI simply requires that PPP be configured to allow for interleaving. Otherwise, LFI is transparent to PPP.
A similar solution is proposed in Internet Engineering Task Force (IETF), INTERNET-DRAFT, “Multi-Class Extension to Multi-Link PPP”, June 1999, expires: December 1999, by Carsten Borman. Here, a fragment oriented solution may be found for the real time encapsulation of format which is part of the standard architecture of, for example, integrated services communications links.
Certain problems associated with conventional LFI, multi-link PPP, and related data transfer may best be illustrated by an example. The transfer of a 1.5 kbyte packet on a 28.8
Olsson Gunnar
Rahlén Simon
Telefonaktiebolaget LN Ericsson (publ)
Yao Kwang Bin
LandOfFree
Method and apparatus for packet delay reduction using... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and apparatus for packet delay reduction using..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for packet delay reduction using... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3158454