Encoding Three Pre-Congestion Notification (PCN) States in the IP Header Using a Single Diffserv Codepoint (DSCP)
RFC 6660

Document Type RFC - Proposed Standard (July 2012; No errata)
Obsoletes RFC 5696
Last updated 2013-02-12
Replaces draft-briscoe-pcn-3-in-1-encoding
Stream IETF
Formats plain text pdf html
Stream WG state WG Document
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 6660 (Proposed Standard)
Telechat date
Responsible AD Martin Stiemerling
IESG note Scott Bradner (sob@harvard.edu) is the document shephed.
Send notices to pcn-chairs@ietf.org, draft-ietf-pcn-3-in-1-encoding@ietf.org
Internet Engineering Task Force (IETF)                        B. Briscoe
Request for Comments: 6660                                            BT
Obsoletes: 5696                                             T. Moncaster
Category: Standards Track                        University of Cambridge
ISSN: 2070-1721                                                 M. Menth
                                                 University of Tuebingen
                                                               July 2012

        Encoding Three Pre-Congestion Notification (PCN) States
       in the IP Header Using a Single Diffserv Codepoint (DSCP)

Abstract

   The objective of Pre-Congestion Notification (PCN) is to protect the
   quality of service (QoS) of inelastic flows within a Diffserv domain.
   The overall rate of PCN-traffic is metered on every link in the PCN-
   domain, and PCN-packets are appropriately marked when certain
   configured rates are exceeded.  Egress nodes pass information about
   these PCN-marks to Decision Points that then decide whether to admit
   or block new flow requests or to terminate some already admitted
   flows during serious pre-congestion.

   This document specifies how PCN-marks are to be encoded into the IP
   header by reusing the Explicit Congestion Notification (ECN)
   codepoints within a PCN-domain.  The PCN wire protocol for non-IP
   protocol headers will need to be defined elsewhere.  Nonetheless,
   this document clarifies the PCN encoding for MPLS in an informational
   appendix.  The encoding for IP provides for up to three different PCN
   marking states using a single Diffserv codepoint (DSCP): not-marked
   (NM), threshold-marked (ThM), and excess-traffic-marked (ETM).
   Hence, it is called the 3-in-1 PCN encoding.  This document obsoletes
   RFC 5696.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6660.

Briscoe, et al.              Standards Track                    [Page 1]
RFC 6660                   3-in-1 PCN Encoding                 July 2012

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Definitions and Abbreviations  . . . . . . . . . . . . . . . .  4
     2.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  List of Abbreviations  . . . . . . . . . . . . . . . . . .  5
   3.  Definition of 3-in-1 PCN Encoding  . . . . . . . . . . . . . .  6
   4.  Requirements for and Applicability of 3-in-1 PCN Encoding  . .  7
     4.1.  PCN Requirements . . . . . . . . . . . . . . . . . . . . .  7
     4.2.  Requirements Imposed by Tunnelling . . . . . . . . . . . .  7
     4.3.  Applicable Environments for the 3-in-1 PCN Encoding  . . .  8
   5.  Behaviour of a PCN-node to Comply with the 3-in-1 PCN
       Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     5.1.  PCN-Ingress-Node Behaviour . . . . . . . . . . . . . . . .  8
     5.2.  PCN-Interior-Node Behaviour  . . . . . . . . . . . . . . . 11
       5.2.1.  Behaviour Common to All PCN-Interior-Nodes . . . . . . 11
       5.2.2.  Behaviour of PCN-Interior-Nodes Using Two
               PCN-Markings . . . . . . . . . . . . . . . . . . . . . 11
       5.2.3.  Behaviour of PCN-Interior-Nodes Using One
               PCN-Marking  . . . . . . . . . . . . . . . . . . . . . 12
     5.3.  PCN-Egress-Node Behaviour  . . . . . . . . . . . . . . . . 13
   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . . 13
     6.1.  Backward Compatibility with ECN  . . . . . . . . . . . . . 13
     6.2.  Backward Compatibility with the Encoding in RFC 5696 . . . 14
Show full document text