RE: [PCN] charter update

[<[e-mail]>]

A quick first one - any chance of sticking with 'termination'? I just
got used to it rather than pre-emption! [I know FLAP is more amusing
than FLAT...]

phil

-----Original Message-----
From: Lars Eggert [mailto:[e-mail]] 
Sent: 23 January 2007 15:15
To: [e-mail]
Subject: [PCN] charter update

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn