Congestion and Pre-Congestion B. Briscoe
Notification BT
Internet-Draft October 27, 2008
Intended status: Experimental
Expires: April 30, 2009
PCN 3-State Encoding Extension in a single DSCP
draft-briscoe-pcn-3-in-1-encoding-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009.
Abstract
Pre-congestion notification (PCN) is a mechanism designed to protect
the quality of service of inelastic flows. It does this by marking
packets when traffic load on a link is approaching or has exceeded a
threshold below the physical link rate. This document specifies an
extension to the two-state PCN baseline encoding that enables three
encoding states to be carried in the IP header without using more
than one Diffserv codepoint. It presupposes a standards action has
removed the limit of two encoding states in current tunnelling
mechanisms.
Briscoe Expires April 30, 2009 [Page 1]
Internet-Draft 3-in-1 PCN Encoding October 2008
1. Introduction
Pre-congestion notification provides information to support admission
control and flow termination at the boundary nodes of a Diffserv
region in order to protect the quality of service (QoS) of inelastic
flows [I-D.ietf-pcn-architecture]. This is achieved by marking
packets on interior nodes according to some metering function
implemented at each node. Excess traffic marking marks PCN packets
that exceed a certain reference rate on a link while threshold
marking marks all PCN packets on a link when the PCN traffic rate
exceeds a higher reference rate [I-D.ietf-pcn-marking-behaviour].
These marks are monitored by the egress nodes of the PCN domain.
To fully support these two types of marking, three encoding states
are needed: one encoding for packets that are not marked plus two
encodings for the two types of marking. The baseline encoding
described in [I-D.ietf-pcn-baseline-encoding] provides for deployment
scenarios that only require two PCN encoding states using a single
Diffserv codepoint. This document describes an experimental
extension to the baseline-encoding that adds a third PCN encoding
state in the IP header, still using a single Diffserv codepoint. For
brevity it will be called the 3-in-1 PCN Encoding.
If more than three states are required, e.g. to support end-to-end
ECN as well as edge-to-edge PCN [I-D.sarker-pcn-ecn-pcn-usecases],
end-to-end ECN would have to be encapsulated in the inner header of a
tunnel through the PCN region, as outlined in
[I-D.ietf-pcn-architecture].
General PCN-related terminology is defined in the PCN architecture
[I-D.ietf-pcn-architecture], and terminology specific to packet
encoding is defined in the PCN baseline encoding
[I-D.ietf-pcn-baseline-encoding].
2. Requirements Language
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 RFC 2119 [RFC2119].
3. The Requirement for Three PCN Encoding States
The PCN architecture [I-D.ietf-pcn-architecture] describes proposed
PCN schemes that expect traffic to be metered and marked using both
Threshold and Excess Traffic schemes. In order to achieve this it is
necessary to allow for three PCN encoding states: one as a Not Marked
Briscoe Expires April 30, 2009 [Page 2]
Internet-Draft 3-in-1 PCN Encoding October 2008
(NM) state and the other two to distinguish these two levels of
marking severity. The way tunnels process the ECN field severely
limits how to encode these states.
The two bit ECN field seems to offer four possible encoding states,
but one (00) is set aside for traffic controlled by transports that
do not understand PCN marking, so it would be irregular to use it as
a PCN encoding state. Of the three remaining ECN codepoints, only
one (11) can be introduced by a congested node within a tunnel and
still survive the decapsulation behaviour of a tunnel egress as
currently standardised. The two remaining codepoints are (10) and
(01). But if a node within the tunnel used either of these two
remaining codepoints to try to mark packets with a second severity
level, this marking would be removed on decapsulation. The ECN field
is constrained to two marking states in this way irrespective of
whether regular IP in IP tunnelling [RFC3168] or IPsec tunnelling
[RFC4301] is used.
One way to provide another encoding state that survives tunnelling is
to use a second Diffserv codepoint
[I-D.moncaster-pcn-3-state-encoding]. Instead, to avoid wasting
scarce Diffserv codepoints, we could modify standard tunnels in the
PCN region to remove the constraints imposed by standard tunnelling.
Therefore this document presupposes tunnels in the PCN region comply
with the newly proposed Comprehensive Decapsulation Rules defined in
Appendix C of [I-D.ietf-tsvwg-ecn-tunnel]. Then the constraints of
standard tunnels no longer apply so this document can define a
3-state encoding for PCN within one Diffserv codepoint.
Note that [I-D.ietf-tsvwg-ecn-tunnel] only records the Comprehensive
Decapsulation Rules in an appendix, solely to allow us to discuss
whether they should be brought on to the standards track. So, if
they are not, the offending tunnelling constraints might not be
removed. However, [I-D.ietf-tsvwg-ecn-tunnel] carefully establishes
that the constraints imposed by standard tunnelling are actually
unnecessary; they are merely the result of an unfortunate sequence of
historical events. Then the analysis in Appendix C of
[I-D.ietf-tsvwg-ecn-tunnel] shows that the proposed new rules would
not introduce any compatibility issues; they only affect one
combination of inner and outer header which has never occured under
any legal transitions of any IETF tunnelling schemes. Therefore it
is a reasonable working assumption for the purposes of this document
that tunnelling constraints will one day be removed.
Briscoe Expires April 30, 2009 [Page 3]
Internet-Draft 3-in-1 PCN Encoding October 2008
4. The 3-in-1 PCN Encoding
The 3-in-1 PCN Encoding scheme is based closely on that defined in
[I-D.ietf-pcn-baseline-encoding] so that there will be no
compatibility issues if a PCN-domain evolves from using the baseline
encoding scheme to the experimental scheme described here. The exact
manner in which the PCN encoding states are carried in the IP header
is shown in Table 1.
Codepoint in ECN field of IP header
<RFC3168 codepoint name>
+--------+--------------+-------------+-------------+---------+
| DSCP | 00 <Not-ECT> | 10 <ECT(0)> | 01 <ECT(1)> | 11 <CE> |
+--------+--------------+-------------+-------------+---------+
| DSCP n | Not-PCN | NM | ThM | ETM |
+--------+--------------+-------------+-------------+---------+
Table 1: 3-in-1 PCN Encoding
In Table 1 the 3 PCN states are encoded in the ECN field ([RFC3168])
of an IP packet with its Diffserv field ([RFC2474]) set to DSCP n,
which is any PCN-Compatible DiffServ codepoint as defined in Section
4.2 of the PCN baseline encoding [I-D.ietf-pcn-baseline-encoding]).
The PCN codepoint of a packet defines its marking state as follows:
Not-PCN: The packet is controlled by a transport that does not
understand PCN marking, therefore the only valid action to notify
congestion is to drop the packet;
NM: Not marked. A packet in the NM state has not (yet) had its
marking state changed to the ThM or ETM states, but it may be
changed to one of these states by a node experiencing congestion
or pre-congestion;
ThM: Threshold marked. Such a packet has had its marking state
changed by the threshold marking algorithm
[I-D.ietf-pcn-marking-behaviour];
ETM: Excess traffic marking. Such a packet has had its marking
state changed by the excess rate marking algorithm
[I-D.ietf-pcn-marking-behaviour].
Packets marked NM, ThM or ETM are termed PCN-Enabled packets because
they are controlled by edge nodes that understand how to process PCN
markings.
Briscoe Expires April 30, 2009 [Page 4]
Internet-Draft 3-in-1 PCN Encoding October 2008
5. Behaviour of a PCN Node Compliant with the 3-in-1 PCN Encoding
To be compliant with the 3-in-1 PCN Encoding, an PCN interior node
behaves as follows:
o It MUST NOT change Not-PCN to a PCN-Enabled codepoint and MUST NOT
change a PCN-Enabled codepoint to Not-PCN;
o It MUST NOT change ThM to NM;
o It MUST NOT change ETM to ThM or to NM;
In other words, a PCN interior node may increase the severity of
packet marking but it MUST NOT decrease it, where the order of
severity increases from NM through ThM to ETM.
6. IANA Considerations
This memo includes no request to IANA.
Note to RFC Editor: this section may be removed on publication as an
RFC.
7. Security Considerations
The security concerns relating to this extended PCN encoding are
essentially the same as those in [I-D.ietf-pcn-baseline-encoding].
8. Conclusions
The 3-in-1 PCN Encoding provides three states to encode PCN markings
in the ECN field of an IP packet using just one Diffserv codepoint.
One state is for not marked packets while the two others are for PCN
nodes to mark packets with increasing levels of severity. Use of the
encoding presupposes that any tunnels in the PCN region have been
updated to use proposed Comprehensive Decapsulation Rules because
standard tunnel decapsulation rules unnecessarily constrain PCN
marking.
9. Acknowledgements
Thanks to Phil Eardley for reviewing this.
Briscoe Expires April 30, 2009 [Page 5]
Internet-Draft 3-in-1 PCN Encoding October 2008
10. Comments Solicited
Comments and questions are encouraged and very welcome. They can be
addressed to the IETF Congestion and Pre-Congestion working group
mailing list <pcn@ietf.org>, and/or to the authors.
11. References
11.1. Normative References
[I-D.ietf-pcn-marking-behaviour]
Eardley, P., "Marking behaviour of PCN-nodes",
draft-ietf-pcn-marking-behaviour-01 (work in progress),
October 2008.
[I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Layered Encapsulation of Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-01 (work in
progress), October 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
11.2. Informative References
[I-D.ietf-pcn-architecture]
Eardley, P., "Pre-Congestion Notification (PCN)
Architecture", draft-ietf-pcn-architecture-08 (work in
progress), October 2008.
[I-D.ietf-pcn-baseline-encoding]
Moncaster, T., Briscoe, B., and M. Menth, "Baseline
Encoding and Transport of Pre-Congestion Information",
draft-ietf-pcn-baseline-encoding-01 (work in progress),
October 2008.
[I-D.moncaster-pcn-3-state-encoding]
Moncaster, T., Briscoe, B., and M. Menth, "A three state
Briscoe Expires April 30, 2009 [Page 6]
Internet-Draft 3-in-1 PCN Encoding October 2008
extended PCN encoding scheme",
draft-moncaster-pcn-3-state-encoding-00 (work in
progress), June 2008.
[I-D.sarker-pcn-ecn-pcn-usecases]
Sarker, Z. and I. Johansson, "Usecases and Benefits of end
to end ECN support in PCN Domains",
draft-sarker-pcn-ecn-pcn-usecases-01 (work in progress),
May 2008.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
Author's Address
Bob Briscoe
BT
B54/77, Adastral Park
Martlesham Heath
Ipswich IP5 3RE
UK
Phone: +44 1473 645196
Email: bob.briscoe@bt.com
URI: http://www.cs.ucl.ac.uk/staff/B.Briscoe/
Briscoe Expires April 30, 2009 [Page 7]
Internet-Draft 3-in-1 PCN Encoding October 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
This document was produced using xml2rfc v1.33 (of
http://xml.resource.org/) from a source in RFC-2629 XML format.
Briscoe Expires April 30, 2009 [Page 8]