Congestion and Pre-Congestion Notification (pcn)
------------------------------------------------

 Charter
 Last Modified: 2011-12-09

 Current Status: Active Working Group

 Chair(s):
     Scott Bradner  <sob@harvard.edu>
     Steven Blake  <slblake@petri-meat.com>

 Transport Area Director(s):
     David Harrington  <ietfdbh@comcast.net>
     Wesley Eddy  <wes@mti-systems.com>

 Transport Area Advisor:
     David Harrington  <ietfdbh@comcast.net>

 Mailing Lists: 
     General Discussion:pcn@ietf.org
     To Subscribe:      pcn-request@ietf.org
         In Body:       (un)subscribe
     Archive:           http://www.ietf.org/mail-archive/web/pcn/index.html

Description of Working Group:

The Congestion and Pre-Congestion Notification (PCN) working group 
develops mechanisms to protect the quality-of-service of established 
inelastic flows within a DiffServ domain when congestion is imminent 
or existing. These mechanisms operate at the domain boundary, based 
on aggregated congestion and pre-congestion information from within 
the domain. The focus of the WG is on developing standards for the 
marking behavior of the interior nodes and the encoding and transport 
of the congestion information. To allow for future extensions to the 
mechanisms and their application to new deployment scenarios, they 
are logically separated into several components, namely, encoding and 
transport along forward path from marker to egress, metering of 
congestion information at the egress, and transport of congestion 
information back to the controlling ingress. Reaction mechanisms at 
the boundary consist of flow admission and flow termination. Although 
designed to work together, flow admission and flow termination are 
independent mechanisms, and the use of one does not require or 
prevent the use of the other. The WG may produce a small number of 
informational documents that describe how specific quality-of-service 
policies for a domain can be implemented using these two mechanisms.

The PCN WG will specify the following components to protect the 
quality-of-service of flows within a DiffServ domain:

(1) a general architecture for flow admission and termination
based on aggregated (pre-)congestion information

(2) a specification of conditions under which interior nodes
generate (pre-)congestion information

(3) encoding and transport of (pre-)congestion information
between the interior and domain egress

(4) metering of (pre-)congestion information at the domain egress

(5) encoding and transport of (pre-)congestion information
between the egress and the controlling domain ingress

(6) ingress node control mechanisms for flow admission or
termination, based on aggregated (pre-)congestion information

The WG focuses on the marking behavior and encoding and transport 
mechanisms needed to realize the overall PCN architecture. Standards- 
track protocols and mechanisms are only developed where necessary for 
interoperability. For other components of the architecture, the WG 
may document examples or provide recommended solutions in 
informational documents. The architecture document will be 
comprehensive, and include security, manageability and operational 
considerations. All PCN mechanisms, including transport and encoding 
of (pre-congestion) information, are required to cleanly integrate 
with existing architectures and protocols such as DiffServ and ECN. 
If the PCN WG requires extensions or modifications to protocols that 
are products of other WGs, it may motivate their need and describe 
requirements in informational documents; design of such extensions 
and modifications will take place in the appropriate WGs.


The initial scope of the PCN WG is restricted by the following 
assumptions:

(A) these components are deployed in a single DiffServ domain,
where all boundary and interior nodes are PCN-enabled
and trust each other for correct PCN marking, encoding, 
transport and aggregation

(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) flows may have different precedence, but the applicability
of the PCN mechanisms for emergency use (911, GETS, WPS, 
MLPP, etc.) is out of scope

After completion of the initial phase, the PCN WG may re-charter to 
develop solutions for scenarios where some of these restrictions are 
not in place. It may also re-charter to consider applying the PCN 
mechanisms to additional deployment scenarios (operation over 
concatenated DiffServ domains, PCN-aware application mechanisms, 
etc.). The WG may also consider to investigate additional response 
mechanisms that act on (pre-)congestion information. One example 
could be flow-rate adaptation (rather than flow admission/ 
termination) during times of congestion. The details of these work 
items are outside the scope of the initial phase; but the WG may 
consider their requirements to design components that are 
sufficiently general to support such extensions in the future.

 Goals and Milestones:

   Done         Submit Pre-Congestion Notification (PCN) Architecture to the 
                IESG for consideration as an Informational RFC 

   Mar 2009       Submit Encoding and Transport of (Pre-) Congestion Information 
                from within a DiffServ Domain to the Egress to the IESG for 
                consideration as a Proposed Standard RFC 

   Mar 2009       Submit (Pre-) Congestion Detection within a DiffServ Domain to 
                the IESG for consideration as a Proposed Standard RFC 

   Mar 2009       Submit Survey of Encoding and Transport Choices of (Pre-) 
                Congestion Information within a DiffServ Domain to the IESG for 
                consideration as an Informational RFC 

   Jul 2009       Submit Requirements for Signaling of (Pre-) Congestion 
                Information from Egress to Ingress in a DiffServ Domain to the 
                IESG for consideration as a Informational RFC 

   Nov 2009       Submit Suggested Flow Admission and Termination Boundary 
                Mechanisms to the IESG for consideration as an Informational 
                RFC 


 Internet-Drafts:

Posted Revised         I-D Title   <Filename>
------ ------- --------------------------------------------
Jul 2009 Aug 2011   <draft-ietf-pcn-3-in-1-encoding-08.txt>
                Encoding 3 PCN-States in the IP header using a single DSCP 

Jul 2009 Jun 2011   <draft-ietf-pcn-encoding-comparison-06.txt>
                Overview of Pre-Congestion Notification Encoding 

Jul 2009 Dec 2011   <draft-ietf-pcn-cl-edge-behaviour-11.txt>
                PCN Boundary Node Behaviour for the Controlled Load (CL) Mode 
                of Operation 

Jul 2009 Dec 2011   <draft-ietf-pcn-sm-edge-behaviour-08.txt>
                PCN Boundary Node Behaviour for the Single Marking (SM) Mode of 
                Operation 

Jul 2010 Jul 2011   <draft-ietf-pcn-signaling-requirements-07.txt>
                Requirements for Signaling of (Pre-) Congestion Information in 
                a DiffServ Domain 

 Request For Comments:

  RFC   Stat Published     Title
------- -- ----------- ------------------------------------
RFC5559 I    Jun 2009    Pre-Congestion Notification (PCN) Architecture 

RFC5670 PS   Nov 2009    Metering and Marking Behaviour of PCN-Nodes 

RFC5696 PS   Nov 2009    Baseline Encoding and Transport of Pre-Congestion 
                       Information