Re: [PCN] charter update

[Lars Eggert <[e-mail]>]

Disregard this. This seems to have been stuck in a queue for 9  
months :-)

On 2007-1-23, at 17:15, ext Lars Eggert wrote:

> 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

_______________________________________________
PCN mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/pcn