[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