doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc5696.txt b/doc/rfc/rfc5696.txt
new file mode 100644
index 0000000..5cc3f3b
--- /dev/null
+++ b/doc/rfc/rfc5696.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                       T. Moncaster
+Request for Comments: 5696                                    B. Briscoe
+Category: Standards Track                                             BT
+                                                                M. Menth
+                                                 University of Wuerzburg
+                                                           November 2009
+
+
+     Baseline Encoding and Transport of Pre-Congestion Information
+
+Abstract
+
+   The objective of the Pre-Congestion Notification (PCN) architecture
+   is to protect the quality of service (QoS) of inelastic flows within
+   a Diffserv domain.  It achieves this by marking packets belonging to
+   PCN-flows when the rate of traffic exceeds certain configured
+   thresholds on links in the domain.  These marks can then be evaluated
+   to determine how close the domain is to being congested.  This
+   document specifies how such marks are encoded into the IP header by
+   redefining the Explicit Congestion Notification (ECN) codepoints
+   within such domains.  The baseline encoding described here provides
+   only two PCN encoding states: Not-marked and PCN-marked.  Future
+   extensions to this encoding may be needed in order to provide more
+   than one level of marking severity.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 BSD License.
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 1]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Requirements Notation  . . . . . . . . . . . . . . . . . . . .  3
+   3.  Terminology and Abbreviations  . . . . . . . . . . . . . . . .  3
+     3.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.2.  List of Abbreviations  . . . . . . . . . . . . . . . . . .  4
+   4.  Encoding Two PCN States in IP  . . . . . . . . . . . . . . . .  4
+     4.1.  Marking Packets  . . . . . . . . . . . . . . . . . . . . .  5
+     4.2.  Valid and Invalid Codepoint Transitions  . . . . . . . . .  6
+     4.3.  Rationale for Encoding . . . . . . . . . . . . . . . . . .  7
+     4.4.  PCN-Compatible Diffserv Codepoints . . . . . . . . . . . .  7
+       4.4.1.  Co-Existence of PCN and Not-PCN Traffic  . . . . . . .  8
+   5.  Rules for Experimental Encoding Schemes  . . . . . . . . . . .  8
+   6.  Backward Compatibility . . . . . . . . . . . . . . . . . . . .  9
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   8.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 10
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+     10.1. Normative References . . . . . . . . . . . . . . . . . . . 10
+     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
+   Appendix A.  PCN Deployment Considerations (Informative) . . . . . 11
+     A.1.  Choice of Suitable DSCPs . . . . . . . . . . . . . . . . . 11
+     A.2.  Rationale for Using ECT(0) for Not-Marked  . . . . . . . . 12
+   Appendix B.  Co-Existence of PCN and ECN (Informative) . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 2]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+1.  Introduction
+
+   The objective of the Pre-Congestion Notification (PCN) architecture
+   [RFC5559] is to protect the quality of service (QoS) of inelastic
+   flows within a Diffserv domain in a simple, scalable, and robust
+   fashion.  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.  These configured rates are below the
+   rate of the link, thus providing notification before any congestion
+   occurs (hence "Pre-Congestion Notification").  The level of marking
+   allows the boundary nodes to make decisions about whether to admit or
+   block a new flow request, and (in abnormal circumstances) whether to
+   terminate some of the existing flows, thereby protecting the QoS of
+   previously admitted flows.
+
+   This document specifies how these PCN-marks are encoded into the IP
+   header by reusing the bits of the Explicit Congestion Notification
+   (ECN) field [RFC3168].  It also describes how packets are identified
+   as belonging to a PCN-flow.  Some deployment models require two PCN
+   encoding states, others require more.  The baseline encoding
+   described here only provides for two PCN encoding states.  However,
+   the encoding can be easily extended to provide more states.  Rules
+   for such extensions are given in Section 5.
+
+2.  Requirements Notation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Terminology and Abbreviations
+
+3.1.  Terminology
+
+   The terms PCN-capable, PCN-domain, PCN-node, PCN-interior-node, PCN-
+   ingress-node, PCN-egress-node, PCN-boundary-node, PCN-traffic, PCN-
+   packets and PCN-marking are used as defined in [RFC5559].  The
+   following additional terms are defined in this document:
+
+   o  PCN-compatible Diffserv codepoint - a Diffserv codepoint
+      indicating packets for which the ECN field is used to carry PCN-
+      markings rather than [RFC3168] markings.
+
+   o  PCN-marked codepoint - a codepoint that indicates packets that
+      have been marked at a PCN-interior-node using some PCN-marking
+      behaviour [RFC5670].  Abbreviated to PM.
+
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 3]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   o  Not-marked codepoint - a codepoint that indicates packets that are
+      PCN-capable but that are not PCN-marked.  Abbreviated to NM.
+
+   o  not-PCN codepoint - a codepoint that indicates packets that are
+      not PCN-capable.
+
+3.2.  List of Abbreviations
+
+   The following abbreviations are used in this document:
+
+   o  AF = Assured Forwarding [RFC2597]
+
+   o  CE = Congestion Experienced [RFC3168]
+
+   o  CS = Class Selector [RFC2474]
+
+   o  DSCP = Diffserv codepoint
+
+   o  ECN = Explicit Congestion Notification [RFC3168]
+
+   o  ECT = ECN Capable Transport [RFC3168]
+
+   o  EF = Expedited Forwarding [RFC3246]
+
+   o  EXP = Experimental
+
+   o  NM = Not-marked
+
+   o  PCN = Pre-Congestion Notification
+
+   o  PM = PCN-marked
+
+4.  Encoding Two PCN States in IP
+
+   The PCN encoding states are defined using a combination of the DSCP
+   and ECN fields within the IP header.  The baseline PCN encoding
+   closely follows the semantics of ECN [RFC3168].  It allows the
+   encoding of two PCN states: Not-marked and PCN-marked.  It also
+   allows for traffic that is not PCN-capable to be marked as such (not-
+   PCN).  Given the scarcity of codepoints within the IP header, the
+   baseline encoding leaves one codepoint free for experimental use.
+   The following table defines how to encode these states in IP:
+
+
+
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 4]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   +---------------+-------------+-------------+-------------+---------+
+   | ECN codepoint |   Not-ECT   | ECT(0) (10) | ECT(1) (01) | CE (11) |
+   |               |     (00)    |             |             |         |
+   +---------------+-------------+-------------+-------------+---------+
+   |     DSCP n    |   not-PCN   |      NM     |     EXP     |    PM   |
+   +---------------+-------------+-------------+-------------+---------+
+
+                        Table 1: Encoding PCN in IP
+
+   In the table above, DSCP n is a PCN-compatible Diffserv codepoint
+   (see Section 4.4) and EXP means available for Experimental use.  N.B.
+   we deliberately reserve this codepoint for experimental use only (and
+   not local use) to prevent future compatibility issues.
+
+   The following rules apply to all PCN-traffic:
+
+   o  PCN-traffic MUST be marked with a PCN-compatible Diffserv
+      codepoint.  To conserve DSCPs, Diffserv codepoints SHOULD be
+      chosen that are already defined for use with admission-controlled
+      traffic.  Appendix A.1 gives guidance to implementors on suitable
+      DSCPs.  Guidelines for mixing traffic types within a PCN-domain
+      are given in [RFC5670].
+
+   o  Any packet arriving at the PCN-ingress-node that shares a PCN-
+      compatible DSCP and is not a PCN-packet MUST be marked as not-PCN
+      within the PCN-domain.
+
+   o  If a packet arrives at the PCN-ingress-node with its ECN field
+      already set to a value other than not-ECT, then appropriate action
+      MUST be taken to meet the requirements of [RFC3168].  The simplest
+      appropriate action is to just drop such packets.  However, this is
+      a drastic action that an operator may feel is undesirable.
+      Appendix B provides more information and summarises other
+      alternative actions that might be taken.
+
+4.1.  Marking Packets
+
+   [RFC5670] states that any encoding scheme document must specify the
+   required action to take if one of the marking algorithms indicates
+   that a packet needs to be marked.  For the baseline encoding scheme,
+   the required action is simply as follows:
+
+   o  If a marking algorithm indicates the need to mark a PCN-packet,
+      then that packet MUST have its PCN codepoint set to 11, PCN-
+      marked.
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 5]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+4.2.  Valid and Invalid Codepoint Transitions
+
+   A PCN-ingress-node MUST set the Not-marked (10) codepoint on any
+   arriving packet that belongs to a PCN-flow.  It MUST set the not-PCN
+   (00) codepoint on all other packets sharing a PCN-compatible Diffserv
+   codepoint.
+
+   The only valid codepoint transitions within a PCN-interior-node are
+   from NM to PM (which should occur if either meter indicates a need to
+   PCN-mark a packet [RFC5670]) and from EXP to PM.  PCN-nodes that only
+   implement the baseline encoding MUST be able to PCN-mark packets that
+   arrive with the EXP codepoint.  This should ease the design of
+   experimental schemes that want to allow partial deployment of
+   experimental nodes alongside nodes that only implement the baseline
+   encoding.  The following table gives the full set of valid and
+   invalid codepoint transitions.
+
+                    +-------------------------------------------------+
+                    |                  Codepoint Out                  |
+     +--------------+-------------+-----------+-----------+-----------+
+     | Codepoint in | not-PCN(00) |   NM(10)  |  EXP(01)  |   PM(11)  |
+     +--------------+-------------+-----------+-----------+-----------+
+     |  not-PCN(00) |    Valid    | Not valid | Not valid | Not valid |
+     +--------------+-------------+-----------+-----------+-----------+
+     |       NM(10) |  Not valid  |   Valid   | Not valid |   Valid   |
+     +--------------+-------------+-----------+-----------+-----------+
+     |     EXP(01)* |  Not valid  | Not valid |   Valid   |   Valid   |
+     +--------------+-------------+-----------+-----------+-----------+
+     |       PM(11) |  Not valid  | Not valid | Not valid |   Valid   |
+     +--------------+-------------+-----------+-----------+-----------+
+        * This MAY cause an alarm to be raised at a management layer.
+          See paragraph above for an explanation of this transition.
+
+          Table 2: Valid and Invalid Codepoint Transitions for
+                       PCN-Packets at PCN-Interior-Nodes
+
+   The codepoint transition constraints given here apply only to the
+   baseline encoding scheme.  Constraints on codepoint transitions for
+   future experimental schemes are discussed in Section 5.
+
+   A PCN-egress-node SHOULD set the not-PCN (00) codepoint on all
+   packets it forwards out of the PCN-domain.  The only exception to
+   this is if the PCN-egress-node is certain that revealing other
+   codepoints outside the PCN-domain won't contravene the guidance given
+   in [RFC4774].  For instance, if the PCN-ingress-node has explicitly
+   informed the PCN-egress-node that this flow is ECN-capable, then it
+   might be safe to expose other codepoints.
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 6]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+4.3.  Rationale for Encoding
+
+   The exact choice of encoding was dictated by the constraints imposed
+   by existing IETF RFCs, in particular [RFC3168], [RFC4301], and
+   [RFC4774].  One of the tightest constraints was the need for any PCN
+   encoding to survive being tunnelled through either an IP-in-IP tunnel
+   or an IPsec Tunnel.  [ECN-TUN] explains this in more detail.  The
+   main effect of this constraint is that any PCN-marking has to carry
+   the 11 codepoint in the ECN field since this is the only codepoint
+   that is guaranteed to be copied down into the forwarded header upon
+   decapsulation.  An additional constraint is the need to minimise the
+   use of Diffserv codepoints because there is a limited supply of
+   Standards Track codepoints remaining.  Section 4.4 explains how we
+   have minimised this still further by reusing pre-existing Diffserv
+   codepoint(s) such that non-PCN-traffic can still be distinguished
+   from PCN-traffic.
+
+   There are a number of factors that were considered before choosing to
+   set 10 as the NM state instead of 01.  These included similarity to
+   ECN, presence of tunnels within the domain, leakage into and out of
+   the PCN-domain, and incremental deployment (see Appendix A.2).
+
+   The encoding scheme above seems to meet all these constraints and
+   ends up looking very similar to ECN.  This is perhaps not surprising
+   given the similarity in architectural intent between PCN and ECN.
+
+4.4.  PCN-Compatible Diffserv Codepoints
+
+   Equipment complying with the baseline PCN encoding MUST allow PCN to
+   be enabled for certain Diffserv codepoints.  This document defines
+   the term "PCN-compatible Diffserv codepoint" for such a DSCP.  To be
+   clear, any packets with such a DSCP will be PCN-enabled only if they
+   are within a PCN-domain and have their ECN field set to indicate a
+   codepoint other than not-PCN.
+
+   Enabling PCN-marking behaviour for a specific DSCP disables any other
+   marking behaviour (e.g., enabling PCN replaces the default ECN
+   marking behaviour introduced in [RFC3168]) with the PCN-metering and
+   -marking behaviours described in [RFC5670]).  This ensures compliance
+   with the Best Current Practice (BCP) guidance set out in [RFC4774].
+
+   The PCN working group has chosen not to define a single DSCP for use
+   with PCN for several reasons.  Firstly, the PCN mechanism is
+   applicable to a variety of different traffic classes.  Secondly,
+   Standards Track DSCPs are in increasingly short supply.  Thirdly, PCN
+   is not a scheduling behaviour -- rather, it should be seen as being
+
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 7]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   essentially a marking behaviour similar to ECN but intended for
+   inelastic traffic.  More details are given in the informational
+   Appendix A.1.
+
+4.4.1.  Co-Existence of PCN and Not-PCN Traffic
+
+   The scarcity of pool 1 DSCPs, coupled with the fact that PCN is
+   envisaged as a marking behaviour that could be applied to a number of
+   different DSCPs, makes it essential that we provide a not-PCN state.
+   As stated above (and expanded in Appendix A.1), the aim is for PCN to
+   re-use existing DSCPs.  Because PCN redefines the meaning of the ECN
+   field for such DSCPs, it is important to allow an operator to still
+   use the DSCP for non-PCN-traffic.  This is achieved by providing a
+   not-PCN state within the encoding scheme.  Section 3.5 of [RFC5559]
+   discusses how competing-non-PCN-traffic should be handled.
+
+5.  Rules for Experimental Encoding Schemes
+
+   Any experimental encoding scheme MUST follow these rules to ensure
+   backward compatibility with this baseline scheme:
+
+   o  All PCN-interior-nodes within a PCN-domain MUST interpret the 00
+      codepoint in the ECN field as not-PCN and MUST NOT change it to
+      another value.  Therefore, a PCN-ingress-node wishing to disable
+      PCN-marking for a packet with a PCN-compatible Diffserv codepoint
+      MUST set the ECN field to 00.
+
+   o  The 11 codepoint in the ECN field MUST indicate that the packet
+      has been PCN-marked as the result of one or both of the meters
+      indicating a need to PCN-mark a packet [RFC5670].  The
+      experimental scheme MUST define which meter(s) trigger this
+      marking.
+
+   o  The 01 Experimental codepoint in the ECN field MAY mean PCN-marked
+      or it MAY carry some other meaning.  However, any experimental
+      scheme MUST define its meaning in the context of that experiment.
+
+   o  If both the 01 and 11 codepoints are being used to indicate PCN-
+      marked, then the 11 codepoint MUST be taken to be the more severe
+      marking and the choice of which meter sets which mark MUST be
+      defined.
+
+   o  Once set, the 11 codepoint in the ECN field MUST NOT be changed to
+      any other codepoint.
+
+   o  Any experimental scheme MUST include details of all valid and
+      invalid codepoint transitions at any PCN-nodes.
+
+
+
+
+Moncaster, et al.           Standards Track                     [Page 8]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+6.  Backward Compatibility
+
+   BCP 124 [RFC4774] gives guidelines for specifying alternative
+   semantics for the ECN field.  It sets out a number of factors to be
+   taken into consideration.  It also suggests various techniques to
+   allow the co-existence of default ECN and alternative ECN semantics.
+   The baseline encoding specified in this document defines PCN-
+   compatible Diffserv codepoints as no longer supporting the default
+   ECN semantics.  As such, this document is compatible with BCP 124.
+
+   On its own, this baseline encoding cannot support both ECN marking
+   end-to-end (e2e) and PCN-marking within a PCN-domain.  It is possible
+   to do this by carrying e2e ECN across a PCN-domain within the inner
+   header of an IP-in-IP tunnel, or by using a richer encoding such as
+   the proposed experimental scheme in [PCN-ENC].
+
+   In any PCN deployment, traffic can only enter the PCN-domain through
+   PCN-ingress-nodes and leave through PCN-egress-nodes.  PCN-ingress-
+   nodes ensure that any packets entering the PCN-domain have the ECN
+   field in their outermost IP header set to the appropriate PCN
+   codepoint.  PCN-egress-nodes then guarantee that the ECN field of any
+   packet leaving the PCN-domain has the correct ECN semantics.  This
+   prevents unintended leakage of ECN marks into or out of the PCN-
+   domain, and thus reduces backward-compatibility issues.
+
+7.  Security Considerations
+
+   PCN-marking only carries a meaning within the confines of a PCN-
+   domain.  This encoding document is intended to stand independently of
+   the architecture used to determine how specific packets are
+   authorised to be PCN-marked, which will be described in separate
+   documents on PCN-boundary-node behaviour.
+
+   This document assumes the PCN-domain to be entirely under the control
+   of a single operator, or a set of operators who trust each other.
+   However, future extensions to PCN might include inter-domain versions
+   where trust cannot be assumed between domains.  If such schemes are
+   proposed, they must ensure that they can operate securely despite the
+   lack of trust.  However, such considerations are beyond the scope of
+   this document.
+
+   One potential security concern is the injection of spurious PCN-marks
+   into the PCN-domain.  However, these can only enter the domain if a
+   PCN-ingress-node is misconfigured.  The precise impact of any such
+   misconfiguration will depend on which of the proposed PCN-boundary-
+   node behaviour schemes is used, but in general spurious marks will
+   lead to admitting fewer flows into the domain or potentially
+   terminating too many flows.  In either case, good management should
+
+
+
+Moncaster, et al.           Standards Track                     [Page 9]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   be able to quickly spot the problem since the overall utilisation of
+   the domain will rapidly fall.
+
+8.  Conclusions
+
+   This document defines the baseline PCN encoding, utilising a
+   combination of a PCN-compatible DSCP and the ECN field in the IP
+   header.  This baseline encoding allows the existence of two PCN
+   encoding states: Not-marked and PCN-marked.  It also allows for the
+   co-existence of competing traffic within the same DSCP, so long as
+   that traffic does not require ECN support within the PCN-domain.  The
+   encoding scheme is conformant with [RFC4774].  The working group has
+   chosen not to define a single DSCP for use with PCN.  The rationale
+   for this decision along with advice relating to the choice of
+   suitable DSCPs can be found in Appendix A.1.
+
+9.  Acknowledgements
+
+   This document builds extensively on work done in the PCN working
+   group by Kwok Ho Chan, Georgios Karagiannis, Philip Eardley, Anna
+   Charny, Joe Babiarz, and others.  Thanks to Ruediger Geib and Gorry
+   Fairhurst for providing detailed comments on this document.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
+              of Explicit Congestion Notification (ECN) to IP",
+              RFC 3168, September 2001.
+
+   [RFC4774]  Floyd, S., "Specifying Alternate Semantics for the
+              Explicit Congestion Notification (ECN) Field", BCP 124,
+              RFC 4774, November 2006.
+
+   [RFC5670]  Eardley, P., Ed., "Metering and Marking Behaviour of PCN-
+              Nodes", RFC 5670, November 2009.
+
+
+
+
+
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                    [Page 10]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+10.2.  Informative References
+
+   [ECN-TUN]  Briscoe, B., "Tunnelling of Explicit Congestion
+              Notification", Work in Progress, July 2009.
+
+   [PCN-ENC]  Moncaster, T., Briscoe, B., and M. Menth, "A PCN encoding
+              using 2 DSCPs to provide 3 or more states", Work
+              in Progress, April 2009.
+
+   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
+              "Definition of the Differentiated Services Field (DS
+              Field) in the IPv4 and IPv6 Headers", RFC 2474,
+              December 1998.
+
+   [RFC2597]  Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
+              "Assured Forwarding PHB Group", RFC 2597, June 1999.
+
+   [RFC3246]  Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
+              J., Courtney, W., Davari, S., Firoiu, V., and D.
+              Stiliadis, "An Expedited Forwarding PHB (Per-Hop
+              Behavior)", RFC 3246, March 2002.
+
+   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
+              Congestion Notification (ECN) Signaling with Nonces",
+              RFC 3540, June 2003.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
+              Guidelines for DiffServ Service Classes", RFC 4594,
+              August 2006.
+
+   [RFC5127]  Chan, K., Babiarz, J., and F. Baker, "Aggregation of
+              DiffServ Service Classes", RFC 5127, February 2008.
+
+   [RFC5559]  Eardley, P., "Pre-Congestion Notification (PCN)
+              Architecture", RFC 5559, June 2009.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                    [Page 11]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+Appendix A.  PCN Deployment Considerations (Informative)
+
+A.1.  Choice of Suitable DSCPs
+
+   The PCN working group chose not to define a single DSCP for use with
+   PCN for several reasons.  Firstly, the PCN mechanism is applicable to
+   a variety of different traffic classes.  Secondly, Standards Track
+   DSCPs are in increasingly short supply.  Thirdly, PCN is not a
+   scheduling behaviour -- rather, it should be seen as being a marking
+   behaviour similar to ECN but intended for inelastic traffic.  The
+   choice of which DSCP is most suitable for a given PCN-domain is
+   dependent on the nature of the traffic entering that domain and the
+   link rates of all the links making up that domain.  In PCN-domains
+   with sufficient aggregation, the appropriate DSCPs would currently be
+   those for the Real-Time Treatment Aggregate [RFC5127].  The PCN
+   working group suggests using admission control for the following
+   service classes (defined in [RFC4594]):
+
+   o  Telephony (EF)
+
+   o  Real-time interactive (CS4)
+
+   o  Broadcast Video (CS3)
+
+   o  Multimedia Conferencing (AF4)
+
+   CS5 is excluded from this list since PCN is not expected to be
+   applied to signalling traffic.
+
+   PCN-marking is intended to provide a scalable admission-control
+   mechanism for traffic with a high degree of statistical multiplexing.
+   PCN-marking would therefore be appropriate to apply to traffic in the
+   above classes, but only within a PCN-domain containing sufficiently
+   aggregated traffic.  In such cases, the above service classes may
+   well all be subject to a single forwarding treatment (treatment
+   aggregate [RFC5127]).  However, this does not imply all such IP
+   traffic would necessarily be identified by one DSCP -- each service
+   class might keep a distinct DSCP within the highly aggregated region
+   [RFC5127].
+
+   Additional service classes may be defined for which admission control
+   is appropriate, whether through some future standards action or
+   through local use by certain operators, e.g., the Multimedia
+   Streaming service class (AF3).  This document does not preclude the
+   use of PCN in more cases than those listed above.
+
+   Note: The above discussion is informative not normative, as operators
+   are ultimately free to decide whether to use admission control for
+
+
+
+Moncaster, et al.           Standards Track                    [Page 12]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   certain service classes and whether to use PCN as their mechanism of
+   choice.
+
+A.2.  Rationale for Using ECT(0) for Not-Marked
+
+   The choice of which ECT codepoint to use for the Not-marked state was
+   based on the following considerations:
+
+   o  [RFC3168] full-functionality tunnel within the PCN-domain: Either
+      ECT is safe.
+
+   o  Leakage of traffic into PCN-domain: Because of the lack of take-up
+      of the ECN nonce [RFC3540], leakage of ECT(1) is less likely to
+      occur and so might be considered safer.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                    [Page 13]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   o  Leakage of traffic out of PCN-domain: Either ECT is equally unsafe
+      (since this would incorrectly indicate the traffic was ECN-capable
+      outside the controlled PCN-domain).
+
+   o  Incremental deployment: Either codepoint is suitable, providing
+      that the codepoints are used consistently.
+
+   o  Conceptual consistency with other schemes: ECT(0) is conceptually
+      consistent with [RFC3168].
+
+   Overall, this seemed to suggest that ECT(0) was most appropriate to
+   use.
+
+Appendix B.  Co-Existence of PCN and ECN (Informative)
+
+   This baseline encoding scheme redefines the ECN codepoints within the
+   PCN-domain.  As packets with a PCN-compatible DSCP leave the PCN-
+   domain, their ECN field is reset to not-ECT (00).  This is a problem
+   for the operator if packets with a PCN-compatible DSCP arrive at the
+   PCN-domain with any ECN codepoint other than not-ECN.  If the ECN-
+   codepoint is ECT(0) (10) or ECT(1) (01), resetting the ECN field to
+   00 effectively turns off end-to-end ECN.  This is undesirable as it
+   removes the benefits of ECN, but [RFC3168] states that it is no worse
+   than dropping the packet.  However, if a packet was marked with CE
+   (11), resetting the ECN field to 00 at the PCN egress node violates
+   the rule that CE-marks must never be lost except as a result of
+   packet drop [RFC3168].
+
+   A number of options exist to overcome this issue.  The most
+   appropriate option will depend on the circumstances and has to be a
+   decision for the operator.  The definition of the action is beyond
+   the scope of this document, but we briefly explain the four broad
+   categories of solution below: tunnelling the packets, using an
+   extended encoding scheme, signalling to the end systems to stop using
+   ECN, or re-marking packets to a different DSCP.
+
+   o  Tunnelling the packets across the PCN-domain (for instance, in an
+      IP-in-IP tunnel from the PCN-ingress-node to the PCN-egress-node)
+      preserves the original ECN marking on the inner header.
+
+   o  An extended encoding scheme can be designed that preserves the
+      original ECN codepoints.  For instance, if the PCN-egress-node can
+      determine from the PCN codepoint what the original ECN codepoint
+      was, then it can reset the packet to that codepoint.  [PCN-ENC]
+      partially achieves this but is unable to recover ECN markings if
+      the packet is PCN-marked in the PCN-domain.
+
+
+
+
+
+Moncaster, et al.           Standards Track                    [Page 14]
+
+RFC 5696                 Baseline PCN Encoding             November 2009
+
+
+   o  Explicit signalling to the end systems can indicate to the source
+      that ECN cannot be used on this path (because it does not support
+      ECN and PCN at the same time).  Dropping the packet can be thought
+      of as a form of silent signal to the source, as it will see any
+      ECT-marked packets it sends being dropped.
+
+   o  Packets that are not part of a PCN-flow but which share a PCN-
+      compatible DSCP can be re-marked to a different local-use DSCP at
+      the PCN-ingress-node with the original DSCP restored at the PCN-
+      egress.  This preserves the ECN codepoint on these packets but
+      relies on there being spare local-use DSCPs within the PCN-domain.
+
+Authors' Addresses
+
+   Toby Moncaster
+   BT
+   B54/70, Adastral Park
+   Martlesham Heath
+   Ipswich  IP5 3RE
+   UK
+
+   Phone: +44 7918 901170
+   EMail: toby.moncaster@bt.com
+
+
+   Bob Briscoe
+   BT
+   B54/77, Adastral Park
+   Martlesham Heath
+   Ipswich  IP5 3RE
+   UK
+
+   Phone: +44 1473 645196
+   EMail: bob.briscoe@bt.com
+
+
+   Michael Menth
+   University of Wuerzburg
+   Institute of Computer Science
+   Am Hubland
+   Wuerzburg  D-97074
+   Germany
+
+   Phone: +49 931 318 6644
+   EMail: menth@informatik.uni-wuerzburg.de
+
+
+
+
+
+
+Moncaster, et al.           Standards Track                    [Page 15]
+