In recent years, network service providers have been upgrading and managing networks based on Multi Protocol Label Switching (MPLS) technology. MPLS has been deployed in most backbone networks. MPLS provides capabilities such as Quality of Service (QoS), redundancy, Operations Administration and Maintenance (OAM), and Virtual Private Network (VPN). MPLS is typically used to provision and manage data streams at individual flow levels. Each flow is known as a Label Switched Path (LSP). Existing MPLS systems typically handle data traffic at the Layer-3 (IP) level and below.
Some MPLS networks use Pseudowires to map Open System Interconnections (OSI) Layer-1 or Layer-2 traffic flows into “virtual circuits.” A Pseudowire refers to the emulation of a Layer-1 or Layer-2 native service over a network. Examples of native services include Asynchronous Transfer Mode (ATM), Frame Relay, Ethernet Virtual Local Area Network (VLAN), Time Division Multiplexing (TDM), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), etc. In the control plane, the Pseudowires are maintained and managed using a simplified version of Label Distribution Protocol (LDP), the Target LDP. Each Pseudowire is associated with an MPLS label for packet forwarding and a control word for flow management.
Since existing MPLS networks only allow Layer-1 or Layer-2 connections to be mapped to Pseudowires in a one-to-one mapping, the system typically cannot guarantee the QoS for individual applications that generate application data in Layer-3 or above. QoS behavior in the application layer is sometimes different from the behavior in Layer-1 or Layer-2. For example, packet video streams can generally tolerate out-of-sequence delivery, and packet voice traffic can sometimes tolerate packet loss but is sensitive to packet delay. Existing Layer-1 and Layer-2 systems, however, typically do not address network-level QoS for these voice and video applications.
Some proposed IP-based models have been developed to address the QoS requirement associated with applications, but some issues remain. For example, the IntServ/RSVP model identifies connections by applications based on the IP addresses of the source and destination, the protocol type, and the protocol's source and destination port number (together known as the 5-tuple). Each connection is required to comply with a number of service parameters such as bandwidth consumption and delay budget. As a result, the intermediate nodes (such as the core routers) are required to store the identity of all the connections, perform deep packet inspection, and implement extensive QoS mechanisms to satisfy the service parameters for each flow. Network service providers tend to find this model limiting because it is not very scalable as the number of users grow.
The DiffServ model addresses the scalability problems associated with the IntServ/RSVP model. Instead of handling QoS on a per flow basis, the user applications are classified into a small number of uniformly defined traffic classes. Each data packet stores its traffic class information in its IP header. At each intermediate node, the packet receives appropriate QoS treatment according to its traffic class. Since DiffServ provides relative QoS, in order to guarantee QoS to a particular flow, the model typically requires the network bandwidth to be over-provisioned. Further, the model only incorporates a subset of available QoS technology, such as priority queuing and Random Early Discard (RED) in dealing with temporary traffic congestion. The model is often not applicable in networks where physical links cannot be sufficiently over-provisioned.
It would be useful to have a way to better manage application traffic over a carrier network without requiring changes to the intermediate nodes. It would also be desirable if QoS guarantee can be achieved at per-application flow level. Furthermore, the solution should to be scalable.
USPTO Backgrounds
USPTO Backgrounds