Multiplex communications – Pathfinding or routing – Switching a message which includes an address header
Reexamination Certificate
1999-04-07
2003-10-14
Marcelo, Melvin (Department: 2663)
Multiplex communications
Pathfinding or routing
Switching a message which includes an address header
C370S394000, C710S054000
Reexamination Certificate
active
06633575
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates in general to a packet forwarding in a network, and more particularly to a method and apparatus for avoiding packet reordering in multiple-class, multiple-priority networks using a queue.
2. Description of Related Art
The primary Internet transport protocols, most importantly the Transmission Control Protocol (TCP), have been very carefully designed and tuned over the past 25 years to support a service model of graceful degradation, where connections are essentially never denied and every connection's performance simply degrades as the network load increases.
Originally designed to interconnect the huge, heterogeneous assortment of computers within the U.S. Government, TCP/IP has since grown into a complete family of “open” (royalty-free) protocols that enable computers to communicate over any combination of local- and wide-area network links. Bundled for many years with UNIX, commercial implementations of TCP/IP are now available for every make and model of computer system. The recent explosive growth in demand for access to the Internet, which is based on TCP/IP, has established TCP/IP as the computer industry's de facto network protocol standard.
The various members of the TCP/IP protocol family work cooperatively in a “stacked” architecture. When a network user (client) requests a certain kind of service, TCP/IP's upper-level protocols invoke the functions of lower protocols to form the necessary network interface.
For example, when a user runs a World Wide Web (WWW) application on a client computer and requests a file to be downloaded from an hyper-text transfer protocol (HTTP) server, the client system's WWW application and its underlying TCP/IP protocol stack software: 1) formulate a protocol request; 2) enclose (encapsulate) the request within one or more Transmission Control Protocol (TCP) packets to ensure its acknowledged delivery; 3) encapsulate each resultant TCP packet within an IP packet, which includes the network address (IP address and port number) of the server; and 4) depending on the underlying LAN or WAN network hardware, encapsulate each IP packet within the appropriate frame for transmission.
The corresponding TCP/IP protocol stack on the server, in turn, decapsulates the incoming frame and acts on the request it contains. Later, the server delivers the requested file to the client by similarly encapsulating and transmitting it through the network.
One of TCP/IP's greatest strengths is its extensible architecture. Over the years, new protocols have occasionally been added to TCP/IP to support innovative network hardware or deliver new kinds of services, without disrupting the operation of existing protocols. New protocols were introduced at the same architectural level and used as an alternative to prior protocols that were found to be insufficient under new applications. As one such example, consider the User Datagram Protocol (UDP), whose introduction as an alternative to TCPI facilitated network applications like the Network File System (NFS) and the Simple Network Management Protocol (SNMP).
While new protocols can be added relatively painlessly to the TCP/IP family, changes to established protocols unavoidably affect existing applications. Consequently, throughout TCP/IP's history, such changes have been made very carefully, and only when absolutely necessary. Changing any protocol in a widely adopted system like TCP/IP can put millions of network users at risk.
Nowhere within TCP/IP is the potential risk of change greater than at the family's central routing function: the Internet Protocol. IP defines the addressing scheme for all TCP/IP devices, and is the central implementation issue in the many thousands of routers that serve the needs of the worldwide Internet community 24 hours a day.
For years now, the members of TCP/IP's regulating organization, the Internet Engineering Task Force (IETF), have known that the current version of IP is in need of an overhaul. After perhaps the most careful design and review process in the history of networking, that long-awaited revision is nearing completion.
Developed over many years of careful design and exhaustive review, the IPv6 (IPng) addressing scheme is radically new, based on the demographic nature of the community it will serve. At the same time, IPv6 includes provisions for upward compatibility from and interpretability with today's IPv4 network architecture.
The service model for which the next generation of the Internet strives is neither strictly the circuit switched model of the telephone system, nor the best-efforts model of the current Internet, but rather an integrated approach where Quality of Service (QoS) traffic coexists with best-effort traffic. The primary design goal behind this approach is to share network resources in such a way that one can simultaneously achieve the benefits of circuit-switched networks (performance guarantees) and the benefits of best-efforts networks (low cost due to resource sharing).
From a desire to find an approach that would be simple, scalable, and relatively easy to deploy in a predominantly best-efforts Internet, the concept of Differentiated Services has originated. In addition, within differentiated services there is significant emphasis on allowing for meaningful end-to-end services to be provisioned across multiple, separately administered network clouds and on keeping the consequent business models as simple as possible.
Accordingly, the goal of the evolving IETF differentiated services (diffserv) framework is to provide a means of offering a spectrum of services in the Internet without the need for per-flow state and signaling in every router. By carefully aggregating a multitude of QoS-enabled flows into a small number of aggregates that are given a small number of differentiated treatments within the network, diffserv eliminates the need to recognize and store information about each individual flow in core routers. This effort to scalability succeeds by combining a small number of simple packet treatments with a larger number of per-flow policing policies to provide a broad and flexible range of services. Each diffserv flow is policed and marked at the first trusted downstream router according to a contracted service profile (usually a token bucket filter). When viewed from the perspective of a network administrator, the first trusted downstream router is a “leaf router” at the periphery of the trusted network. Downstream from the nearest leaf router, a diffserv flow is mingled with similar diffserv traffic into an aggregate. All subsequent forwarding and policing is performed on aggregates.
Current proposals for marking packets designate the “per-hop behaviors” (PHBs) that packets are to receive by setting a few bits in the IPv4 header TOS octet or the IPv6 Traffic Class octet—now renamed the “DS field”. The PHBs are expected to be simple and define forwarding behaviors that may suggest, but do not require, a particular implementation or queuing discipline. Examples include: “drop me last” or “forward me first”. Keeping the number of PHBs small and the behaviors themselves simple should allow router designers to engineer diffserv packet forwarders that operate at very high packet per second rates.
Another important benefit of handling traffic aggregates is to simplify the construction of end-to-end services from the concatenation of multiple cloud-to-cloud services. Individual network clouds contract with neighboring clouds to provide differentiated service contracts for different traffic aggregates. Like the per-flow contracts, aggregate contracts are characterized by profiles (again, often based on token bucket filters). By carefully enforcing the aggregate traffic profiles and ensuring that new traffic is not admitted that exceeds any aggregate profile, well-defined end-to-end services may be provided over chains of separately administered clouds. Furthermore, since each aggregate contracts exists only at the boundary bet
Ferris Derrick W.
Marcelo Melvin
Nokia Corporation
Squire Sanders & Dempsey LLP
LandOfFree
Method and apparatus for avoiding packet reordering in... 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 avoiding packet reordering in..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for avoiding packet reordering in... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3164496