Pre-Congestion Notification (PCN) Architecture

This document describes a general architecture for flow admission and termination based on pre-congestion information in order to protect the quality of service of established, inelastic flows within a single Diffserv domain.\u

QUALITY OF SERVICE ARCHITECTURES APPLICABILITY IN AN INTRANET NETWORK

The quality of service (QoS) concept, which appeared initially as a necessity to improve Internet users perception, deals actually with new valences along with information society maturation. At the organisation’s level, the Intranet network shall assure in a similar manner as the Internet all kinds of services, which are useful to the organisation’s users. Starting from the traditional QoS architectural models, network administrators shall plan and design a QoS architecture, which will map on the organisation’s requirements, having at disposal not only own network elements but also communication services provided by other operators. The aim of this paper is to present, starting from the general QoS models, a comparative study of main advantages and drawbacks in implementing a specific Intranet QoS architecture taking into consideration all kind of aspects (material, financial, human resources), which impact on a good Intranet QoS management.QoS, IntServ, DiffServ, IntServ over DiffServ, VPN-MPLS, Intranet network

Flow-based reservation marking in MPLS networks

2007-2008 > Academic research: refereed > Refereed conference paperVersion of RecordPublishe

Overview of Pre-Congestion Notification Encoding

The objective of Pre-Congestion Notification (PCN) is to protect the quality of service (QoS) of inelastic flows within a Diffserv domain. On every link in the PCN-domain, the overall rate of PCN-traffic is metered, and PCN-packets are appropriately marked when certain configured rates are exceeded. Egress nodes provide decision points with information about the PCN-marks of PCN-packets that allows them to take decisions about whether to admit or block a new flow request, and to terminate some already admitted flows during serious pre-congestion. The PCN working group explored a number of approaches for encoding this pre-congestion information into the IP header. This document provides details of those approaches along with an explanation of the constraints that apply to any solution

Pre-Congestion Notification Encoding Comparison

DiffServ mechanisms have been developed to support Quality of Service (QoS). However, the level of assurance that can be provided with DiffServ without substantial over-provisioning is limited. Pre-Congestion Notification (PCN) investigates the use of per-flow admission control to provide the required service guarantees for the admitted traffic. While admission control will protect the QoS under\ud normal operating conditions, an additional flow termination mechanism is necessary in the times of heavy congestion (e.g. caused by route changes due to link or node failure).\ud Encoding and their transport are required to carry the congestion and pre-congestion information from the congestion and pre-congestion points to the decision points. This document provides a survey of\ud several encoding methods, using comparisons amongst them as a way to explain their strengths and weaknesses.\u

Pre-Congestion Notification marking

Pre-Congestion Notification (PCN) builds on the concepts of RFC 3168, "The addition of Explicit Congestion Notification to IP". However, Pre-Congestion Notification aims at providing notification before any congestion actually occurs. Pre-Congestion Notification is applied to \ud real-time flows (such as voice, video and multimedia streaming) in DiffServ networks. As described in [CL-DEPLOY], it enables "pre" congestion control through two procedures, flow admission control and flow pre-emption. The draft proposes algorithms that determine when a \ud PCN-enabled router writes Admission Marking and Pre-emption Marking in a packet header, depending on the traffic level. The draft also proposes how to encode these markings. We present simulation results with PCN working in an edge-to-edge scenario using the marking algorithms described. Other marking algorithms will be investigated in the future. \u

RMD (Resource Management in Diffserv) QoS-NSLP model

This draft describes a local QoS model, denoted as Resource Management in Diffserv (RMD) QoS model, for NSIS that extends the IETF Differentiated Services (Diffserv) architecture with a scalable admission control and resource reservation concept. The specification of this QoS model includes a description of its QoS parameter information, as well as how that information should be treated or interpreted in the network

TCP flow aware adaptive path switching in diffserv enabled MPLS networks

Cataloged from PDF version of article.We propose an adaptive flow-level multi-path routing-based traffic engineering solution for an IP backbone network carrying TCP/IP traffic. Incoming TCP flows are switched between two explicitly routed paths, namely the primary and secondary paths (PP and SP), for resilience and potential goodput improvement at the TCP layer. In the proposed architecture, PPs receive a preferential treatment over SPs using differentiated services mechanisms. The reason for this choice is not for service differentiation but for coping with the detrimental knock-on effect stemming from the use of longer SP that is well known for conventional network load balancing algorithms. Moreover, both paths are congestion-controlled using Explicit Congestion Notification marking at the core and Additive Increase Multiplicative Decrease rate adjustment at the ingress nodes. The delay difference between PP and SP is estimated using two per-egress rate-controlling buffers maintained at the ingress nodes for each path, and this delay difference is used to determine the path over which a new TCP flow will be routed. We perform extensive simulations using ns-2 in order to demonstrate the viability of the proposed distributed adaptive multi-path routing method in terms of per-flow TCP goodput. The proposed solution consistently outperforms the single-path routing policy and provides substantial per-flow goodput gains under poor PP conditions. Moreover, highest goodput improvements under the proposed scheme are achieved by flows that receive the lowest goodputs with single-path routing, while the performance of the flows with high goodputs with single-path routing does not deteriorate with the proposed path switching technique. Copyright # 2011 John Wiley & Sons, Ltd