[PCN] charter update
Lars Eggert <lars.eggert@nokia.com> Thu, 25 October 2007 12:04 UTC
Return-path: <pcn-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1Rx-0005oz-9J; Thu, 25 Oct 2007 08:04:33 -0400
Received: from pcn by megatron.ietf.org with local (Exim 4.43) id 1Il1Rw-0005os-Ay for pcn-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 08:04:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il1Rv-0005ok-Ll for pcn@ietf.org; Thu, 25 Oct 2007 08:04:31 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il1Ro-0001FQ-7D for pcn@ietf.org; Thu, 25 Oct 2007 08:04:31 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PC4DKP021183 for <pcn@ietf.org>; Thu, 25 Oct 2007 15:04:18 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:03:46 +0300
Received: from mgw-int02.ntc.nokia.com ([172.21.143.97]) by esebh104.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 Oct 2007 15:03:46 +0300
Received: from [172.21.35.48] (esdhcp03548.research.nokia.com [172.21.35.48]) by mgw-int02.ntc.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9PC3i3m020421 for <pcn@ietf.org>; Thu, 25 Oct 2007 15:03:44 +0300
Mime-Version: 1.0 (Apple Message framework v752.3)
To: pcn@ietf.org
Message-Id: <75FEE0DB-D9D7-4738-A68A-E816D08B03C7@nokia.com>
From: Lars Eggert <lars.eggert@nokia.com>
Date: Tue, 23 Jan 2007 17:15:18 +0200
X-Mailer: Apple Mail (2.752.3)
X-OriginalArrivalTime: 25 Oct 2007 12:03:46.0234 (UTC) FILETIME=[186D31A0:01C816FF]
X-Nokia-AV: Clean
X-Spam-Score: 2.3 (++)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
Subject: [PCN] charter update
X-BeenThere: pcn@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PCN WG list <pcn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pcn>
List-Post: <mailto:pcn@ietf.org>
List-Help: <mailto:pcn-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pcn>, <mailto:pcn-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1365258119=="
Errors-To: pcn-bounces@ietf.org
Hi, as mentioned previously, I have edited the charter proposal posted to this list in December to reflect the discussions that have occurred on- and off-list. The main changes are a removal of the SIP, application-based and pseudowire deployment scenarios, a restructuring of the initial deliverables and milestones, and a set of stronger retrictions. Please send comments! Lars Description of Working Group: The Flow Admission and Preemption (FLAP) working group develops flow admission and flow preemption mechanisms for deployment along the edge of a network domain that protect the quality-of-service that previously-admitted flows experience within the domain during times of congestion. These mechanisms act on aggregated congestion and pre- congestion signals from routers within the network domain and control the admission of new flows into the domain or preempt previously- admitted flows. Although designed to work together, flow admission and flow preemption are independent mechanisms, and the use of one does not require the use of the other. The FLAP WG will specify the following components of an integrated flow admission and preemption mechanism: (1) a general architecture for flow admission and preemption based on aggregated (pre-)congestion signals (2) conditions under which interior routers generate (pre-)congestion signals (3) encoding and transport of (pre-)congestion signals to the appropriate ingress routers of the network domain (4) edge router control mechanisms for flow admission and preemption based on aggregated (pre-)congestion information The WG focuses on the overall architecture and specifically the signaling interfaces needed to realize it. Standards-track protocols are only developed when necessary for interoperability. When algorithms are not necessary for interoperability the WG may document examples or provide recommended solutions, however such work should not be done at the expense of normative specifications. The initial scope of the FLAP WG is restricted in the following ways: (A) develop these components for a single DiffServ region, where all edge and interior routers are FLAP-enabled and mutually trust each other (B) all flows handled by these mechanisms are inelastic and constrained to a known maximum rate through policing or shaping (C) the number of flows across any potential aggregation bottleneck is sufficiently large for stateless, statistical mechanisms to be effective (D) aggregation occurs either on links or ingress/egress pairs; mechanisms must further define relevant limits (E) flows may have different precedence, but the applicability of these mechanisms for emergency use (911, GETS, WPS, MLPP, etc.) is out of scope After completion of the initial phase, the FLAP WG may recharter to develop solutions for scenarios where some of these restrictions are not in place. It may also recharter to consider applying the FLAP mechanisms to additional deployment scenarios (operation over concatenated DiffServ regions, FLAP-aware application mechanisms, etc.). The WG may also consider to investigate additional response mechanisms that act on (pre-)congestion signals. One example could be flow-rate adaptation (rather than flow admission/preemption) during times of congestion. The details of these work items are outside the scope of the initial phase; but the WG may want to However in the initial scope this mechanism is out-of-scope with the exception that the developed solution should not, if possible, prevent a future evolution to support this. Goals and Milestones: Jul 2007 Flow Admission and Preemption Architecture (Informational) Jul 2007 Survey of Encoding and Transport Choices of (Pre-)Congestion Signals within a DiffServ Region (Informational) Nov 2007 Flow Admission and Preemption within a DiffServ Region (Informational) Nov 2007 (Pre-)Congestion Detection within a DiffServ Region (Proposed Standard) Mar 2008 Encoding and Transport of (Pre-)Congestion Signals within a DiffServ Region to Flow Egress (Proposed Standard) Mar 2008 Transport from Flow Egress in a DiffServ Region of information (possibly aggregated) or Admission/Preemption Signals to DiffServ edge devices. (Proposed Standard) Mar 2008 Suggested Flow Admission and Preemption Edge Mechanisms (Informational)
_______________________________________________ PCN mailing list PCN@ietf.org https://www1.ietf.org/mailman/listinfo/pcn
- [PCN] charter update Lars Eggert
- RE: [PCN] charter update philip.eardley
- Re: [PCN] charter update Lars Eggert
- RE: [PCN] charter update philip.eardley