Flow termination signaling in the centralized pre-congestion notification architecture

Pre-congestion notification (PCN) protects inelastic traffic by using feedback on network link loads on and acting upon this accordingly. These actions comprise to admission control and termination of flows. Two PCN architectures have been defined by IETF: the centralized and decentralized PCN architecture. The decentralized PCN architecture has received much attention in the literature whereas the centralized PCN architecture has not. In the decentralized architecture, feedback is sent from the egress nodes to ingress nodes, which then take and apply decisions regarding admission of new flows and/or termination of ongoing flows. Signaling occurs only between ingress and egress nodes. In the centralized architecture these decisions are made at a central node, which requires proper signaling for action and information exchange between the central node and the egress and ingress nodes. This signaling has been suggested by other authors, but is not fully defined yet. Our contribution is twofold. We define signaling in the centralized PCN architecture focussing on flow termination, which completes the definition of the signaling in the centralized PCN architecture. Secondly, we run extensive simulations showing that the proposed signaling works well and that the performances of the centralized PCN and the decentralized PCN architectures are similar. Hence, it is expected that results from existing research on the effectiveness of decentralized PCN are also valid when the centralized PCN architecture is used

Requirements for Signaling of Pre-Congestion Information in a Diffserv Domain

Pre-Congestion Notification (PCN) is a means for protecting quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo describes the requirements for the signaling applied within the PCN- domain: (1) PCN-feedback-information is carried from the PCN-egress-node to the Decision Point; (2) the Decision Point may ask the PCN-ingress-node to measure, and report back, the rate of sent PCN-traffic between that PCN-ingress-node and PCN-egress-node. The Decision Point may be either collocated with the PCN-ingress-node or a centralized node (in the first case, (2) is not required). The signaling requirements pertain in particular to two edge behaviors, Controlled Load (CL) and Single Marking (SM)

Pre-Congestion Notification (PCN) Boundary-Node Behavior for the Single Marking (SM) Mode of Operation

Pre-Congestion Notification (PCN) is a means for protecting the quality of service for inelastic traffic admitted to a Diffserv domain. The overall PCN architecture is described in RFC 5559. This memo is one of a series describing possible boundary-node behaviors for a PCN-domain. The behavior described here is that for a form of measurement-based load control using two PCN marking states: not-marked and excess-traffic-marked. This behavior is known informally as the Single Marking (SM) PCN-boundary-node behavior

Protecting video service quality in multimedia access networks through PCN

The growing popularity of video-based services and their corresponding unpredictable bursty behavior makes the design of an admission control system an important research challenge. The pre-congestion notification (PCN) mechanism is a measurement-based approach, recently standardized by the IETF, optimized toward the admission of inelastic flows, where the number of flows is sufficiently large that individual bursts of flows can be compensated by silence periods of others. In this article, we discuss the implications of applying PCN to protect video services, which have less predictable behavior. Several algorithms for protecting video services in multimedia access networks are described. Through performance evaluation, we show the impact of these algorithms on the network utilization and video quality, and present guidelines on how to configure a PCN system

QoS Design Consideration for Enterprise and Provider’s Network at Ingress and Egress Router for VoIP protocols

Compliance with the Service Level Agreement (SLA) metric is a major challenge in a Multiprotocol Label Switching Virtual Private Network (MPLS VPN) because mandatory models must be maintained on both sides of the MPLS VPN in order to achieve end-to-end service levels. The end-to-end service of an MPLS VPN can be degraded owing to various issues such as distributed denial of service (DDoS), and Random Early Detection (RED) that prevents congestion and differentiates between legitimate and illegitimate user traffic. In this study, we propose a centralized solution that uses a SLA Violation Detector (SLAVD) and intrusion detection to prevent SLA violation

Protocols, performance assessment and consolidation on interfaces for standardization – D3.3

The following document presents a detailed description of the protocol for the “ Control Channels for the Cooperation of the Cognitive Management System ” (C4MS) which provides the necessary means to enable proper management of Opportunistic Networks. Additionally, the document defines the methodology that was applied for the purpose of signalling evaluation. The protocol overview presented in section 2 of the main document, provides the C4MS principles. The section includes, among others, the description of the protocol identifiers, procedures, protocol state machines and message format as well as the security asp ects. Section 3 provides a high-level description of the data structures defined within the scope of OneFIT project. The data structures are classified into five categories, i.e.: Profiles, Context, Decisions,Knowledge and Policies. The high level description is complemented by some detailed data structures in the Appendix to D3.3 Section 3[10]. Section 4 provides details on the evaluation methodology applied for the purpose of C4MS performance assessment. The section presents the evaluation plan along with a description of metrics that are to be exploited in the scope of WP3. Section 5 and Section 6 are composed of the signalling evaluation results. Section 5 focuses on the estimation of the signalling load imposed by ON management in different ON phases. Additionally some results for the initialization phase (not explicitly mentioned in the previous phases of the project)and security related aspects are also depicted. Section 6 on the other hand is focused on the evaluation of the signalling traffic generated by different ON related algorithms. Conclusions to the document are drawn in section 7. Detailed description of the C4MS procedures, implementation options based on IEEE 802.21, DIAMTER and 3GPP are depicted in the appendix to the D3.3[10] . Additionally, the appendix incorporates the detailed definition of the information data structures and final set of Message Sequence Charts (MSCs) provided for the OneFIT project.Peer ReviewedPreprin